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ABSTRACT 


The Computer Aided Prototyping System (CAPS) developed at the Naval 
Postgraduate School is a powerful Computer Aided Software Engineering 
(CASE) tool for examining requirements and timing constraints for hard real-time 
systems. However, it remains a stand-alone system. Even if it is running on 
machines in multiple locations, there is no way to coordinate the efforts between 
the different locations. In today’s software development environment, that proves 
to be a significant disadvantage. Additionally, providing support for more than 
just hard real-time software development would tremendously enhance CAPS. 

Our analysis details the requirements needed to make a distributed CAPS 
feasible. A distributed CAPS functioning over a network in a coordinated manner 
would be an invaluable asset to those developing software today, especially in 
the Department of Defense (DOD). Our work also produced an initial design 
architecture based on a three tiered client-server model and utilizing Java and 
the Common Object Request Broker Architecture (CORBA). The Java/CORBA 
combination greatly simplifies deploying a distributed CAPS over any 
heterogeneous network. Our preliminary implementation of CAPS with a NT 
client and a Solaris server demonstrates the efficacy of this design. 
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I. INTRODUCTION 




In recent years, more and more attention has been placed on developing better 
methods for the production of software. This results from the fact that hardware has 
simultaneously dropped in price dramatically and increased in performance while 
software has continued to be plagued by cases of bug prone productions, incomplete 
designs that don’t function as desired and in some high profile incidents, software 
projects that had to be abandoned as hopeless. Often the culprit in these cases is a 
poor understanding of the user's requirements. This leads to incomplete or erroneous 
functionality in a software system that, with traditional methods, remains undiscovered 
until near the end of development when the user sees a working product for the first 
time. At this point, it is difficult and very expensive to correct requirement deficiencies. 
This situation led to the concept of prototyping software systems early in development 
so that requirements could be validated in time to easily make changes before problems 
became too deeply rooted. The first prototypes were largely coded manually. This 
made timely analysis difficult. Today, technology has matured to the point that 
automatic generation of prototypes is not only feasible but practical as well [CHAV95]. 
As the software development process has become more and more distributed, a need 
has arisen for distributed prototyping tools. 

A. BACKGROUND 

In the traditional waterfall method of software development, requirements 
analysis and subsequent design were done before little, if any, actually coding was 
done. This helped to preclude the analysis and design being unduly influenced by 
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implementation constraints or biases. However, the draw back was that once 
promulgated, these decisions tended to be seen as set in stone. Even if they were 
reviewed later in the development cycle, it was difficult to update them. The major 
drawback though was that the customer only saw their requirements on paper. Possibly 
they had some conceptual drawings of an interface, but clearly that was not interactive 
at all. This led to customers who didn't get hands-on experience with their product until 
some sort of alpha version was developed. At this point the project was nearing 
completion and making fundamental changes, even simple ones, was very difficult. The 
result was expensive software that did not perform as the customer actually wanted it to 
and was probably delivered late. Clearly there had to be a better way to develop 
software. 

That better way is prototyping. The idea is simple but powerful. Take the 
customer's requirements and create executable models to allow customers to clarify the 
desired system functionality. The tremendous advantage of this was the customer had 
a model not drawn on paper but one that could be interacted with on the computer. The 
developer could use a prototype to help explain the system design to the customer. 
Customer feedback was immediate and clarification of requirements by the customer 
much clearer. Since the investment of time and effort to produce a prototype was 
relatively small and it was early in the development process, changes that the customer 
wanted were easily accommodated. However, the prototype was still largely a hand- 
coded product. In order to reach its full potential, prototyping would have to become 
even more timely. 






Automation was the only way for prototyping to become timelier. This necessity 
led to the development of the Computer Aided Prototyping System (CAPS) at the Naval 
Postgraduate School [LUQI88a,LUQI96]. The goal of CAPS is to improve the efficiency 
and accuracy of evolutionary software development by providing tools that make it 
possible for the developer to quickly and systematically construct and execute 
prototypes [DAMP92]. Much effort has gone into achieving the goal of automating the 
prototyping process and the results thus far are impressive. However, the biggest 
drawback to wider use of CAPS is that it remains a local system. This makes it difficult, 
if not impossible, to coordinate a large project with many designers. The reality of 
software production today is that a team that is geographically dispersed will most likely 
carry out the development of any particular system. Thus to unlock the full potential of 
CAPS, it is necessary to implement it in a distributed, network environment. 

B. THESIS OBJECTIVES 

A significant amount of research has gone into developing CAPS. However, 
today CAPS is implemented on a stand alone UNIX system. This arrangement has 
served the research done to date quite well. To unlock the potential that exists in CAPS 
though, it must become more versatile. This means making CAPS available to a wider 
client base and this requires distributing it over a network. That could be simply a local 
area network (LAN) but that would only be a half step. It should also be deployable 
over a wide area network (WAN) since more and more collaborators on projects are 
located over physically remote sites. Any discussion about a LAN or especially a WAN 
must first acknowledge the certainty that the network will be heterogeneous. Thus 
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many of the assumptions made when CAPS was a stand-alone system will no longer be 
valid. 

Any architecture and subsequent implementation of CAPS on a network will have 
to address many requirements. The high reliability required in a prototyping system 
such as CAPS will be an even greater challenge in a distributed environment. Isolating 
errors in a stand-alone system is relatively easy when compared to the same process in 
a distributed environment. As the distributed environment grows, high availability 
becomes more important. Since the network is sure to be heterogeneous, the 
correctness of the system will depend on maintaining the consistency and integrity of 
the data as it is passed throughout an environment that includes a variety of operating 
systems, machine hardware and programming languages. 

These are only a few of the more obvious obstacles to providing a distributed 
implementation of CAPS. Some of the problems will have straightforward, readily 
available answers. But due to the uniqueness of CAPS, many will not. Thus a 
comprehensive requirements analysis is imperative if CAPS is to be successfully 
deployed in a distributed environment. 

1. Requirements for a Distributed CAPS 

With CAPS operating on a stand-alone UNIX system, it is possible to make many 
simplifying assumptions. Consequently, much of the current design will have to be 
reexamined. However, distributing CAPS is more complicated than simply taking the 
current system and putting it on a network. Before creating a design and architecture, 
the requirements themselves must be reevaluated. It is possible, indeed almost certain, 
that adapting CAPS to a distributed environment will alter many of the requirements that 
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led to the creation of CAPS. Below are characteristics that need to included in the 
requirements analysis for distributing CAPS. 

What will be the nature of the actual physical environment? The degree of 
transparency must be decided. It is assumed that any distributed network will be 
heterogeneous but that doesn't mean that it will necessarily support any hardware or 
operating system that is connected to the network. Exactly what will be supported must 
be determined. Will it be installed on a LAN, WAN or some other network design? The 
amount of fault tolerance must be considered. System performance encompasses 
several issues. What is the minimum system hardware requirement to be enforced? 
The amount of latency that can be tolerated will affect the design and must be 
determined. Is scalability important to a distributed CAPS? It may be possible to 
decide that there are practical limits to the size of any useful implementation. As with 
any distributed system, security becomes a much bigger concern. Certainly cost is a 
consideration if you want to widely deploy any system, as is ease of use. Ease of use 
will also include questions about the effectiveness of training. A key requirement will be 
the constraints placed on what language reusable components can be written in. The 
healthy population of the database of reusable components is critical to CAPS reaching 
its full potential, thus the impediments to achieving that goal should be as few as 
possible. 

2. Design Issues for a Distributed CAPS 

The nature of the distributed architecture will determine many of the design 
specifics. What type of architecture is best for CAPS? The architecture can be 
centralized, replicated throughout the network, or something in between. One of the 
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most fundamental design questions deals with how to handle components. This is 
much more complicated and less straightfonward than in an undistributed system. How 
different components communicate with each other must be decided and will be 
affected by where they are located. Closely associated with the question of 
communication is what degree of mobility components will have and how they will be 
synchronized. Components are not the only entities that must specify their behavior in 
a distributed environment. Data itself is severely influenced by the architectural design. 
What sort of access will users have to data in a distributed CAPS? It can be shared, 
distributed or some form of shared-distributed [PROT96]. The details of how persistent 
storage will operate must be consistent with the handling of data. 

There is a collection of other design questions to be answered in addition to how 
components and data will behave. The mechanism for creation and subsequent 
destruction of process and threads must be specified. This must accommodate not only 
a distributed environment but the possibility of multi-processor machines within the 
network. With processes and data distributed throughout a network, provisions must be 
made for handling distributed exceptions. At the management level, distributed CAPS 
must provide for version control and merging of distributed data. The strategy for 
dealing with both of these functions will be critical to successfully distributing CAPS. It 
will be futile to take advantage of the improved productivity offered by distributing CAPS 
if a coherent, correct prototype is not the ultimate product. 

A final consideration throughout the design process will be how or whether to 
reuse parts of the existing CAPS system. Clearly, some of it must be radically 
reengineered to support operations in a distributed network. However, much of the 
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current system may be useable in a distributed environment. Deciding what to keep 
unchanged and what to alter will be a constant balancing act. Any design must weigh 
the performance improvement associated with any change to the existing system 
against the cost of implementing that change. 
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II. BACKGROUND 


The history of software prototyping shares many similarities with the larger 
subject of software engineering, and indeed with most emerging technologies. It has 
been the source of great debate and confusion as software engineers sought to define 
exactly what it was and how best to use it. Indeed, the debate and research continues 
unabated into what exactly constitutes the best way to prototype and how to use it most 
effectively. The one point that most software engineers agree upon is that the larger, 
increasingly complex systems of today can be more efficiently produced with the aid of 
prototypes. Thus, before looking too far into the future it would be valuable to take a 
look at the past and how we got to where we are today in working with software 
prototypes. 

A. WHY PROTOTYPE AT ALL? 

As computer languages came into existence, a rather simple method of 
developing software emerged. It was simply code and fix. A programmer would sit 
down and write a program, run it and then try to fix the things that didn't work. This 
approach was sufficient for small, relatively uncomplicated programs. But just as 
structured programming emerged to bring some cohesion to writing computer programs 
and in turn was replaced by the object oriented paradigm, the code and fix method of 
developing software systems was destined to fall by the way side. As systems became 
more complicated and ever larger, one person was no longer able to do the amount of 
work required. The amount of work was even more than small groups of software 
engineers and programmers could handle. As more people became involved in the 
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process, it became clear that a better process was needed to create software systems. 
This led to the waterfall model of software development. 

1. The Waterfall Method 

The waterfall model, defined by Royce [ROYC76] and refined by Boehm 
[BOEH76], introduced some rigor and discipline to the development process. No longer 
was code written in isolation from the bigger picture of what the system should actually 
do and then tested to see where it didn't work. Instead, the process was partitioned into 
well-defined development phases. Now there would be a comprehensive investigation 
to determine the requirements of the system, followed by design, implementation and 
finally testing before a system was released. In theory, this systematization of the 
process of producing software systems would result in improved productivity and better 
systems. To a large degree it succeeded in achieving the desired results. However, as 
systems continued to swell in size and complexity, it became clear that there existed 
some serious shortcomings with the waterfall method as well. 

Foremost amongst these is the need to establish the requirements for the 
systems at the beginning of the development process. This is true for several reasons. 
Customers may not know exactly what they want the final system to really do or they 
may not clearly define their needs to the developers. Also, requirements can change 
due to alterations in the environment that the system will operate in, even while the 
system is being developed. Also, during system development, requirements can 
emerge that were overlooked or unanticipated initially. Whatever the reasons for 
changing, incomplete or missing requirements, one thing was for certain. Inaccurate 
requirements, left unchecked, propagated throughout the entire system and resulted in 
software systems that were late, over budget and performed poorly. Sometimes entire 
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projects were abandoned as beyond salvaging, as it became clear that they would 
never perform as expected. As seen in Figures 2.1 and 2.2, most of the problems 
experienced by systems result from inadequacies with the requirements and the later 
these deficiencies are corrected, the more expensive the fix becomes. 


Time Spent in Each Phase Source of Errors 




Relative Cost of Error Correction 


Stage 

Relative Cost of Repair 

Requirements 

1 

Design 

5 

Implementation 

10 

Unit Test 

20 

Acceptance 

50 

Maintenance 

100 


Figure 2.1 The Importance of Early Requirement Validation From [WOOD92] 


11 





incorrect omission inconsistency ambiguity misplaced 
fact requirement 


Figure 2.2 Types of Errors in Requirements From [WOOD92] 


The dilemma confronted by software developers with the waterfall model is aptly 
summed up in a report of the Defense Science Board Task Force on Military Software 
[DSB87]. 


We believe that users cannot, with any amount of effort and wisdom, 
accurately describe the operational requirements for a substantial 
software system without testing by real operators in an operational 
environment, and iteration on the specification. The systems built today 
are just too complex for the mind of man to foresee all the ramifications 
purely by the exercise of the analytic imagination. 
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This inability to completely anticipate all the requirements of system being developed 
lead to the creation of the spiral model [BOEH86] for software engineering. 

2. The Spiral Model 

The spiral model, shown in Figure 2.3, moved the software development process 
from being documentation driven to one that is risk driven. In other words, instead of 
concentrating on completing the current phase in the development process before 
moving on to the next phase, you start by identifying the areas with the highest risk and 
as you develop a strategy for dealing with each one you then tackle the next lower area 
of risk. In essence you have a series of mini-waterfall evolutions but the power of the 
spiral method is that the requirements do not have to all be known before you start. 
Instead, you are defining them as you "spiral" through iteration after iteration, solving 
the hardest part of the system first and working your way to the areas of relatively less 
risk. Prototyping certainly is not required to execute the spiral model of development 
but it can dramatically improve the efficiency of the model. If the problem domain of the 
system being developed is low risk and well understood, it is possible to use what 
essentially amounts to a waterfall method of development. However, this is usually true 
only in uninteresting or trivial systems. In most cases a system is being created for an 
area that is not well understood, either by user or developers or maybe even both. 
Especially in the Department of Defense, this is often the case since many of the 
systems being developed are at the cutting edge of technology or beyond. 

This is when the power of prototyping becomes clear. By allowing developers to 
present a mock-up of a system early in development, it is possible to get user feedback 
in a much more timely manner. This capability makes the spiral method of development 
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much more effective since developers can now produce prototypes throughout the 
iterative development process and use the responses from the ultimate end user to 
continually refine the requirements. Thus when a final product is delivered, it is much 
more likely that the system will function as expected. This avoids a great deal of 
maintenance effort and expense that normally goes into modifying a delivered system in 
order to get it to do what the user really wanted in the first place. 



Figure 2.3 Spiral Model From [BOEH86] 







This leads to consideration about what the ultimate role of the prototype is within 
the development process. While there are many variations and differing names, there 
are two basic purposes for prototypes, both within and outside the spiral model. 
Prototypes can be either exploratory or implementation oriented. Exploratory, also 
referred to as experimental or evaluative, prototypes are used to better understand 
some specific requirement or limitation. The intention is that they will be used and 
discarded after providing the required information and insight. Implementation 
prototypes on the other hand will ultimately become the actual system being developed. 
The biggest practical difference is simply how they are created. An exploratory 
prototype which will be "thrown away" after being used does not have to concern itself 
too much with things such as efficiency, robustness, readability, etc. It must only 
function in a manner that allows the developers, and possibly the users, to better 
understand the question under consideration. The implementation oriented prototype 
must perform in such a manner that the code it produces is of production quality. 

3. Summary of Prototyping Goals 

No matter which approach to prototyping a development team uses, there are 
some general goals for prototyping that pertain to any software system development 
effort. Not every goal is necessarily applicable to every prototype, but they provide a 
framework for how prototyping can improve any development effort. 

• Help systems engineers, users and developers to better understand and 
communicate about the environment and specific problem requirements and 
to transfer design intent amongst themselves; 
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• Demonstrate what is actually feasible, a specific system behavior or some 
element of the proposed system’s performance: 

• Use as a mechanism for getting the users involved earlier than in traditional 
software development processes thus potentially creating a more useful 
system; and 

• Get a production version, of improved quality, completed in less time than 
with traditional methods without prototyping. 

B. THE EVOLUTION OF PROTOTYPING SYSTEMS 

Exactly what constitutes a prototype and how you create one has been the 
subject of much debate and research. While there will probably never be one definitive 
prototype model that everyone accepts, it is illuminating to review a sampling of the 
systems that have been fielded. Not every system evaluated meets the definition of a 
prototype but they all have contributed to the evolution of prototyping systems. 

1. Automatic Code Generators 

One of the earliest attempts at improving the software development process was 
the idea of having program source code automatically generated. Any productive and 
useful prototyping system today will have to incorporate some automatic code 
generation or it will be too cumbersome to be effective. The success of current 
prototyping systems owes much to the work done on automatic code generation. 
However, automatic code generation by itself as a stand-alone development method 
has many shortcomings. Assuming that you are confident that the code being 
generated is actually correct, there is the question of what it was derived from. Often, 
automatic code generation amounts to not much more than instantiating a template 
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according to the user's specifications. The better code generation systems such as 
Graphical Approach to Modeling and Building Interactively a Technical System 
(GAMBITS) [POWE96] are still restricted to a fairly narrow domain. They start small 
using rigid models and keep extending the systems being developed until a useful 
system is produced. However, useful prototypes are not part of the process and it is still 
up to the developers, users and system analysts to ensure that correct requirements are 
implemented. Therefore they are limited outside their respective problem domain. 

2. Requirements Specification Systems 

The goal of a requirements specification system is to capture the complete 
requirements for a system. Often poor communications result in missed, inaccurate or 
incomplete requirements and thus the specifications on which implementation will 
ultimately depend are flawed. A requirements specification system will not produce a 
prototype but the research done in this area has improved current prototyping systems 
as well as automatic code generating systems and executable specification languages. 

3. Executable Specification Language 

Executable specification languages, such as PAISLey [ZAVE91] and the Jackson 
Development System (JSD) [ROLL91], represent the operational approach to software 
development. The operational approach incorporates three phases into the 
development process - modeling, specification and implementation. It closely 
resembles the automatic code development paradigm and when done iteratively also 
resembles the spiral method of development. The modeling though is not a mock-up or 
prototype of some part of a system. Rather it is a model of the relationships that will 
exist when the system “operates.” Thus they suffer from the same shortcomings as 
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automatic code generating systems. Namely, the difficult task of correctly specifying 
requirements still exists and the system produced will be limited to a relatively narrow 
problem domain such as a data intensive business application or database interactions. 
The operational approach to software development is not adequate for the prototyping 
of more general behavior. 

4. Megaprogramming Systems 

Megaprogramming is the attempt to develop systems from existing modules. 
Two examples are the Common Prototyping Language (CPL), a Defense Advanced 
Research Project Agency initiative that became Prototyping Technology (Prototech) 
[KIMB92] and the earlier Rapid Prototyping to Investigate End-user Requirements 
(RaPIER) [WELC86]. Megaprogramming is therefore a more sophisticated form of code 
reuse. As such, it can be an effective way to better explore a relatively well 
documented problem domain or one for which work is already underway. However, it is 
limited as a tool for probing new requirements though. It is problematic to write the 
code for the modules to be combined without first having a good understanding of the 
domain and the requirements of the proposed system. 

5. Prototyping Languages 

As prototyping research gained momentum, it became clear to some that the 
ideal prototyping system would have at its core a language specifically developed for 
the task. Adapting existing languages invariably lead to shortcomings and 
compromises in the functionality of the prototyping system. PROTEUS [MILL90] and 
Durra [BARB91] were two attempts to develop a prototyping language. PROTEUS is 
intended for prototyping parallel and distributed environments. It contains set 
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theoretical notation with a small set of mechanisms for controlling parallel execution. It 
relies on a shared variable model of concurrency and focuses on regulating 
synchronization and communication. Durra is a task description language for 
developing distributed applications. It constructs a program by having the user specify 
the distributed application structure and the resources allocated to each component. 
The developer must still code each task and process but templates exist for creating the 
necessary interfaces. 

The limitations on languages such as PROTEUS and Durra are that they are 
designed for relatively narrow domains and they cannot function without some sort of 
support system. There is no user interface, such as a graphical user interface (GUI), to 
aid developers. You cannot simply load them into your computer and start designing 
prototypes. So while the idea of developing languages specifically for prototyping is 
important for any viable prototyping system, it is still just one of several elements 
needed. 

6. Computer Aided Software Engineering (CASE) Tools 

The natural result of all the research into different aspects of prototyping was the 
creation of CASE tools that combined many of the disparate areas of research into one 
synergistic mechanism for producing prototypes. CAPS and Proto [ACOS94] are two 
such systems. Where CAPS focuses on applications in the hard real time problem 
domain, Proto operates on distributed, parallel systems. Proto provides, as does 
CAPS, a design environment for the system analyst using the System Specification and 
Design Language (SSDL). The design environment includes execution support, a GUI 
and software reuse in order to make it a comprehensive, efficient tool for developing 



prototypes. This total integration of specialized prototyping language and tailored 
support environment is necessary to unlock the full potential that prototyping offers to 
software development. 

There have been attempts to create prototyping systems without the overhead of 
creating the specialized, integrated system described above. They attempt to model 
prototypes using tools based on such things as Petri nets or relational databases. 
However, these tools are cumbersome and ultimately limited in their application. 

7. Prototyping Systems Summary 

The above discussion of the history of prototyping systems is not comprehensive 
but simply representative of the different areas of research that have contributed to the 
considerable body of knowledge concerning software development with prototypes. As 
with any technology, software development is an ever-changing entity. Currently, the 
iterative approach of the spiral method of software development promises the best 
chance of creating software systems that actually satisfy the requirements specified by 
the user. The key to making it effective for anything except trivial systems is the ability 
to rapidly produce prototypes to examine proposed system behavior. Many of the 
research efforts involving prototyping have contributed to the field and then fallen into 
disuse as their productiveness reached practical limits. CAPS has weathered the 
turbulence that accompanies any emerging technology and today is not only alive but a 
vital, leading research tool in creating prototypes for supporting software system 
development. 
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C. CAPS DEVELOPMENT 

As the importance of prototyping to determining system behavior during 
development became clear, it also became obvious that to be effective prototypes 
would have to be created quickly. The requirement for a means to rapidly prototype 
leads to the seemingly obvious conclusion that a computer aided tool needed to be 
fabricated for this effort to succeed. At the time, the most successful systems for 
automatically generating code were focused in narrow problem domains and relied 
upon templates or generic solutions. In order to achieve the type of powerful, 
automated prototyping system envisioned, a computer language would have to be 
design specifically for this purpose. That language was Prototype System Description 
Language (PSDL) [LUQI88b]. The objective of PSDL was to mechanically create 
documents that could be processed and executed at the specification level. In other 
words, PSDL was designed to be an executable prototyping language at the 
specification or design level. 

As CAPS is built around PSDL, PSDL provides more than simply an executable 
prototyping language. Queries to search the database repository of reusable software 
components are based on PSDL. CAPS incorporates a GUI with which the system 
designer can graphically represent the desired requirements. CAPS will transform this 
graphical description into PSDL. Once in PSDL, the Ada components can be generated 
and bound together. After compilation, CAPS provides the facilities for graphically 
displaying the prototype. This allows system behavior to be evaluated and the 
necessary changes made to requirements in a timely manner. Thus, CAPS supports an 
iterative approach to software system development. 
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D. PROTOTYPING RISKS 

It would be unfair and unrealistic to think that prototyping does not incur some 
risks. It is certainly not the fabled silver bullet but simply a means for increasing the 
efficiency and accuracy of the system development process. It is important to 
understand the shortcomings of prototyping in order to take full advantage of its 
tremendous potential. Some of the risks associated with prototyping are; 

• overly enthusiastic developers who want to continually iterate and evolve a prototype 
by adding additional functionality beyond that which was originally being 
investigated; 

• classification of a prototyping effort as rapid can lead managers to think that this 
area can easily absorb budget cuts and shortcuts without affecting the product; 

• the temptation to substitute a prototype that appears to work for a fully documented 
and tested final product; and 

• a misunderstanding about the purpose of prototyping in the development process by 
users or customers can lead to acrimony with the development team and 
compromise the close working relationship that produces the best results. 

E. THE FUTURE 

CAPS today is an energetic, productive research effort into the use of rapid 
prototyping for software development. Its contributions are many and continue to 
appear at an impressive rate. Distributing CAPS itself certainly will ensure its lasting 
viability. Perhaps, however, even more is needed if CAPS is to remain at the leading 
edge of this research field and eventually become a mature product widely used 
throughout commercial software development. Focusing only on the domain of hard 
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real time applications is certainly becoming a limitation. The not too distant future, 
actually beginning to appear already, will see the emergence of applications that 
combine the requirements of hard real time constraints with concurrent operation across 
distributed networks that are growing seemingly without bound. Failure to support such 
applications risks being left on the sidelines or marginalized into some software 
development niche. 
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III. REQUIREMENTS ANALYSIS FOR DEPLOYING CAPS IN A DISTRIBUTED 

ENVIRONMENT 

Fielding a sound, usable system doesn't occur by happenstance or even simply 
hard work. It is the result of a great deal of careful analysis and planning long before 
any implementation ever begins. If the requirements are not properly detailed, you can 
easily end up with a system that does something very well but does not do what the 
customer wanted. If the architecture is not precise, the development can spin out of 
control during implementation as each ambiguity results in a workaround. These 
workarounds and individual interpretations of what the designers meant compound on 
each other until system cohesion begins to suffer. The goal of this chapter is to 
fabricate the foundation of a clear and logical requirements analysis. 

A. CREATING A WELL DESIGNED SYSTEM 

The goal of any system design should be the production of a system that is 
effective, efficient, robust and maintainable. Currently, the best way to achieve that goal 
is through rigorously applying the techniques of object-oriented analysis and design. 
Modeling is the underpinning that makes object-oriented analysis and design 
successful. Through modeling, everyone involved in the development process, from 
stakeholders to testers to managers, can come to a clear understanding and agreement 
about how the system will ultimately perform. Today, the state of the practice for 
modeling is the Unified Modeling Language (UML). 

1. UML Overview 

UML was designed to be as flexible as possible. In fact, it can be applied to 
almost any process, not just software design. It is meant to simply be a tool in the 
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software engineers toolkit. However, it can be a very powerful tool. Utilized to its 
fullest, UML can be integrated into a project from the outset while searching for the 
complete requirements and used through designing the architecture, implementing the 
desired system and finally testing the production code. It is a language that focuses on 
the conceptual and physical nature of a system. Thus it can be used to build the 
blueprints for a software system. Specifically, UML is designed for the visualizing, 
specifying, constructing and documenting of software artifacts [BOOC99]. 

a. Visualizing 

UML helps a system developer record and present to others the ideas 
he/she has. This can be a tremendously powerful way of fostering communication 
between the stakeholders, developers, project managers, users and any other 
interested party. 

b. Specifying 

UML capitalizes on the improved communications by allowing the 
developer, using his/her enhanced understanding of the system objectives, to build 
models that are precise, unambiguous and complete. 

c. Constructing 

The developer can directly connect the models to various programming 
languages. Thus, it is possible to generate programming source code in languages 
such as Ada, C++ and Java. 
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d. Documenting 

Many artifacts will be produced during a development cycle while using 
UML. These can form the basis of a thorough, persistent documentation effort. 

2. Using UML to Redesign CAPS 

As stated before, UML is only a tool in the software design process. It is not a 
set-in-stone, explicitly detailed process. Rather, it is up to the developer to decide how 
to best employ UML. UML gives you the structural pieces for creating a solid design but 
there are many ways to actually put the pieces together. The nature of UML though 
lends itself to best supporting a spiral or incremental development approach. 

We view this work as the beginning effort in redesigning CAPS for the future. 
Our goal is to first establish the requirements for an improved, distributed CAPS. The 
requirements are just a description of the needs and desires for what a system should 
do when deployed. Although this is a simple idea, it is critically important. If the 
requirements are not clearly and accurately defined, all that comes afterwards in the 
development process can be easily compromised. We have chosen to work with the 
UML model in this effort because we believe it can be easily extended in follow on 
theses. 

Our methodology in defining the requirements for the next CAPS will be to first 
determine the necessary system functions and attributes. Next, we will promote a 
better understanding of the processes involved with the application of use cases. 
Finally, we will complete the analysis with a proposed conceptual diagram. We strongly 


believe that this will be the key to a successful design and implementation phase in the 
future. 

B. METHODOLOGY SPECIFICS 

The methodology we used for determining the requirements is detailed below. 

1. System Functions 

Simply stated, the system functions are what the system should actually do in the 
real world. System attributes, on the other hand, are non-functional system qualities. 
System functions can placed in one of two categories - evident or hidden. The user is 
aware when evident functions are being performed. The performance of hidden 
functions is not visible to the user. Often, underlying technical services, such as saving 
information to a persistent storage mechanism, are hidden. 

Constraints and details influence system attributes. These also fall into two 
categories - must and want. In reality, if a constraint is truly real, it should be classified 
as only must. Thus it is only attribute details that are characterized as must or want. 

2. Use Cases 

Simply put, use cases are a narrative description of domain processes that 
highlight the interactions between the system being designed and external agents. 
External agents can be such things as people, other systems, computers or processes. 
According to the creators of the UML, a use case is a description of a set of sequence 
actions that a system performs that yields an observable result to a particular actor. A 
use case is used to structure the behavioral things in a model. [BOOC99] 

Capturing the intended behavior of the system being designed is the goal of a 
use case. This facilitates easier, more complete communication end users, domain 
experts and developers. Use cases help draw attention to high risk areas sooner by 
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fostering clearer investigations of domain processes. Any discussion of implementation 
should be avoided in use cases. The goal is to discuss what should be done, not how 
to do it. However, use cases can be utilized to corroborate about a proposed 
architecture. Two types of use case will be of interest in reengineering CAPS. First, 
high-level use cases will demonstrate all the interactions between actors and the 
system in very general terms. It provides a broad-brush overview of what the system 
should accomplish. The more interesting or critical use cases will be further detailed in 
expanded use cases. Finally, a use case diagram will link the narrative use cases to 
the UML. 

Use cases can help validate the rules of interactions between actors and actors 
or actors and the system. Exploration of the variations on scenarios can result from use 
case discussions. Often, nontrivial scenarios will have alternate paths of action 
revealed during such discussions and possibly one of them will be an improvement on 
the original idea. The crucial characteristic is work should always be accomplished. In 
other words, something should be done that's of value to an actor. 

Lastly, use cases can form the basis for developing test plans. As use cases 
are modified, the changes needed in the test plan are clearly established. A use case 
gives the test developer a straightfon/vard, plain language narrative of what is supposed 
to happen. As use cases can be easily extended and more detailed throughout the 
development process, they make it possible to easily support a spiral or incremental 
development methodology. 

3. Conceptual Model 

The conceptual model illustrates meaningful concepts, i.e. ,objects, in a problem 
domain. Decomposition by concepts supports object oriented analysis whereas 


29 



r 


structural analysis is decomposition by processes or functions. Developing a 
comprehensive set of objects is the key to successful object oriented analysis. A static 
structures diagram expresses the conceptual model in UML. The concepts are 
identified and their attributes delineated as well as their associations with other 
concepts. There are no methods listed though. This construction serves to emphasize 
the fact that concepts in the conceptual model are representing real world entities and 
not software components. The concepts will be derived from the use cases and 
functional requirements. 

C. REQUIREMENTS ANALYSIS RESULTS 

The results of the initial requirements analysis for reengineering CAPS are 
detailed below. 

1. Functional Requirements 

The functional requirements for a reengineered CAPS are listed in Tables 3.1 - 
3.7 grouped by various user inputs, system management, network support and project 
management 


Table 3.1 User Input Functions-Requirements Analysis 


Ref# 

Function 

Function 

Category 

Attribute 

Details and 
Constraints 

Detail 

Category 

HI 

Record stakeholder 
comments 

evident 

interface 

metaphor 

form driven text 
format 

must 

R1.2 

Record user comments 

evident 

interface 

metaphor 

form driven text 
format 

must 

R1.3 

Record requirements for 
the system being 
developed 

evident 

interface 

metaphor 

form driven text 
format 

must 
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Table 3.2 User Input Functions-System Modeling/Specification 


Ref# 

Function 

Function 

Category 

Attribute 

Details and 
Constraints 

Detail 

Category 

R1.4 

Model hard real time 
systems 

evident 

interface 

metaphor 

graphical user 
interface for flow 
diagram and form 
metaphor input for 
hard real time 
constraints 

must 

R1.5 

Model distributed 
systems 

evident 

interface 

metaphor 

graphical user 
interface for flow 
diagram and form 
metaphor input for 
distributed system 
constraints 

must 

R1.6 

Model concurrent 
systems 

evident 

interface 

metaphor 

graphical user 
interface for flow 
diagram and form 
metaphor input for 
concurrent system 
constraints 

must 

RL7 

Model any combination 
of hard real time, 
concurrent or distributed 
system 

evident 

interface 

metaphor 

graphical user 
interface for flow 
diagram and form 
metaphor input for 
hard real time, 
concurrent and/or 
distributed system 
constraints 

must 


Table 3.3 User Input Functions-Prototype Development 


Ref# 

Function 

Function 

Category 

Attribute 

Details and 

Constraints 

Detail 

Category 

R1.8 

Translate PSDL code 
into 3*^^ generation object 
oriented language source 
code 

evident 

response time 

source code will be 
generated in less than 

2 minutes 

want 

R1.9 

Edit prototype source 
code 

evident 

response time 

source code will be 
available in less than 

10 seconds 

want 

Rl.lO 

Compile software 
modules in a prototype 

evident 

response time 

object code will be 
generated in less than 

2 minutes 

want 

Rl.ll 

Link compiled modules 
in a prototype 

evident 

response time 

linking will be 
completed in less than 

2 minutes 

want 

R1.12 

Execute prototype 

evident 

platform 

prototype must be able 
to execute on UNIX 
and 

Windows95/98/NT 

must 


31 















































Table 3.3 User Input Functions-Prototype Development (continued) 


R1.13 

Statically check hard 
real-time timing 
constraints for system 
prototype 

evident 

response time 

complete timing 
validation in less than 

1 minute 

want 

R1.14 

Dynamically check hard 
real-time timing 
constraints for system 
prototype 

evident 

fault tolerance 

identify violations of 
timing constraints 
while executing 

must 

R1.15 

Dynamically report 
network collisions for 
distributed system ‘ 
prototype 

evident 

fault tolerance 

identify details of 
simulated network 
collisions while 
executing 

must 

R1.16 

Dynamically record 
synchronization details 
for system prototype 

evident 

fault tolerance 

identify details of 
simulated network 
timing while executing 

must 

R1.17 

Save component to local 
persistent storage 

hidden 

response time 

save should execute in 
less than 1 minute 

want 

R1.18 


hidden 

response time 

save should execute in 
less than 1 minute 

want 

R1.19 

Commit component to 
persistent storage 

hidden 

response time 

commit should 
execute in less than 1 
minute 

want 

R1.20 

Commit project to 
persistent storage 

hidden 

response time 

commit should 
execute in less than 1 
minute 

want 


Table 3.4 User Input Functions-Reuse 


Ref# 

Function 

Function 

Category 

Attribute 

Details and 
Constraints 

Detail 

Category 

R1.21 

Select software module 
from reuse database 

evident 

shared 

component 

access 

provide matches in 
less than 1 minutes 

want 

R1.22 

Save software modules 
to reuse database 

hidden 

shared 

component 

access 

provide Software 
Librarian controls for 
reuse database 

must 

R1.23 

Delete software modules 
from reuse database 

hidden 

shared 

component 

access 

provide Software 
Librarian controls for 
reuse database 

must 


32 





























Table 3.5 System Administration 


Ref# 

Function 

Function 

Category 

Attribute 

Details and 
Constraints 

Detail 

Category 

R2.1 

Allow Software 

Librarian to add new 
users to access list for 
software component 
database 

hidden 

scalability 

allow enough users to 
support very large 
system development 

must 

R2.2 

Allow Software 

Librarian to delete new 
users from access list for 
software component 
database 

hidden 

scalability 

allow enough users to 
support very large 
system development 

must 

R2.3 

Allow project manager 
to grant file access to 
specific users 

hidden 

security 

only allow authorized 
user to access a project 

must 


Allow project manager 
to revoke file access to 
specific users 

hidden 

security 

only allow authorized 
user to access a project 

must 

R2.5 

Recover from a local 
system failure 

hidden 

fault tolerance 

Restore system back to 
a safe state after a 
local failure 

must 

■ 

Recover from a global 
application failure 

hidden 

fault tolerance 

Restore system back to 
a safe state after 
system wide 
application failure 

must 

R2.7 

Recover from a local 
application failure 

hidden 

fault tolerance 

Restore system back to 
a safe state after a 
local application 
failure 

must 


Table 3.6 Network Support 


i^mi 

Function 

Function 

Category 

Attribute 

Details and 
Constraints 

Detail 

Category 

R3.1 

Transmit module to a 
remote site 

hidden 

shared 

component 

access 

securely get work 
from one site to 
another site 

must 

R3.2 

Download module from 
a remote site 

hidden 

shared 

component 

access 

securely get work 
from one site to 
another site 

must 


Detect errors in 
transmission of modules 

hidden 

fault tolerance 

ensure integrity of 
modules moving over 
network 

must 


Generate alert for 
detected errors in 
transmission 

hidden 

fault tolerance 

ensure integrity of 
modules moving over 
network 

must 
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Table 3.6 Network Support (continued) 


R3.5 

Recover from a global 
system failure 

hidden 

fault tolerance 

Restore system back to 
a safe state after 
system wide failure 

must 

R3.6 

Acknowledge error-free 
transmission of module 

Hidden 

fault tolerance 

ensure integrity of 
modules moving over 
network 

must 


Table 3.7 Project Management 


Ref# 

Function 

Function 

Category 

Attribute 

Details and 

Constraints 

Detail 

Category 

R4.1 

User must log in 
securely in order to use 
system 

evident 

response time 

less than 10 seconds 

want 

R4.2 

Create new project 

evident 

response time 

less than 5 seconds 

want 

R4.3 

Load existing project 

evident 

response time 

less than 10 seconds 

want 

R4.4 

Record version for all 
software artifacts 

hidden 

ease of use 

system must track and 
record order in which 
artifacts entered 

must 

R4.5 

Add component to 
project 

evident 

response time 

component should 
included in project in 
less than 1 minute 

want 

R4.6 

Merge components from 
different sources into 
one component 

evident 

ease of use 

system must 
automatically merge 
components, tracking 
versions 

must 

R4.7 

Merge components from 
different sources into 
one project 

evident 

ease of use 

system must 
automatically merge 
components, tracking 
versions 

must 

R4.8 

Alert project manager to 
conflicts during merge 
operations 

evident 

version control 

system must identify 
version conflicts and 
inform the project 
manager 

must 




response time 

Project manager 
should be alerted in 
less than 2 minutes 

want 
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2. High-level Use Cases 

The high-level use case are detailed below. 




Use Case: 

Actors: 

Type: 

Overview: 

Cross Reference: 


U1. Start-up 
System Administrator 
primary 

System Administrator logs onto host system and initiates CAPS. 
Functions: R2.5, R2.6, R2.7, R3.5 


Use Case: 
Actors: 

Type: 

Overview: 


Cross Reference: 


U2. Log in 
User 

primary 

After CAPS is initiated, a user must log into CAPS in order to 
determine what project and reuse database privileges the user 
owns. 

Functions: R2.3, R4.1 


Use Case: 
Actors: 
Type: 
Overview: 


Cross Reference: 


U3. Open project 

User 

primary 

After logging into CAPS, user can either open a new project or 
select an existing project and open it, if he has the proper 
authorization from the project manager. 

Functions: R2.3, R4.2, R4.3 
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Use Case: 
Actors: 
Type: 
Overview: 


Cross Reference: 

Use Case: 

Actors: 

Type: 

Overview: 


Cross Reference: 


U4. Modify prototype 

User 

primary 

After opening a project, the user will be able to make changes to 
the graphical interface of the control flow diagram or to the text 
boxes associated with either objects or data streams in the 
diagram. These changes will be automatically reflected in the 
PSDL code. The user can record user comments, stakeholder 
comments and requirements for the system being prototyped. 
Additionally, the user can directly access the PSDL code and 
change it manually. 

Functions: R1.1, R1.2, R1.3, R1.4, R1.5, R1.6, R1.7, R1.21, R4.4, 
R4.5 


U5. Retrieve component from reuse database 

User 

primary 

The user accesses the reuse database and inputs search 
parameters. CAPS responds with no match, unique match or a list 
of possible matches. CAPS generates an alert if there is an error in 
transmission and an acknowledgement if the transfer is successful. 
Functions: R1.21, R3.2, R3.4, R3.6 
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Use Case: 


U6. Save 


Actors: 

Type: 

Overview: 

Cross Reference: 

Use Case: 

Actors: 

Type: 

Overview: 

Cross Reference: 

Use Case: 

Actors: 

Type: 

Overview: 


Cross Reference: 


User 

primary 

User has opened a project or component and now saves it to local 
persistent storage. 

Functions: R1.17, R1.18 

U7. Modify GUI for displaying prototype execution 

User 

primary 

User selects and then edits the files that provide functionality for 
displaying prototype execution. 

Functions: R1.4. R1.5, R1.6, R1.7, R1.8, R1.9 

U8. Generate executable prototype 

User 

primary 

The user translates the prototype in order to create source code in 
an implementation language from the PSDL and link it. The user 
will then verify through CAPS that all static hard real time 
constraints are met. The user will then compile the prototype 
source code. 

Functions: R1.9, R1.10, R1.11 
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Use Case: 
Actors: 
Type: 
Overview: 


Cross Reference: 

Use Case: 

Actors: 

Type: 

Overview: 


U9. Execute the prototype 

User 

primary 

The user will execute the prototype. As the user test the prototype 
functionality, CAPS will verify that all dynamic hard real time, 
concurrency and network constraints are met. CAPS will allow the 
user to record stakeholder and/or user comments. 

Functions: R1.1. R1.2, R1.3, R1.12, R1.13, R1.14, R1.15. R1.16 

U10. Manage project changes 
User, Project Manager 
primary 

User (possibly more than one) will submit module(s) to the Project 
Manager for incorporation into the project prototype. The user may 
elect to return the entire prototype after making changes to only 
some of the modules. In this case the Project Manager must 
identify which modules are changed or new. If the module does not 
already exist in the project database, the Project Manager will 
merge the submitted module(s) into one module, resolving any 
conflicts. CAPS will assign and track a version number and insert 
the module into the project database, making ties to all other 
modules that may exist in the project database. If the module 
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Cross Reference: 

Use Case: 

Actors: 

Type: 

Overview: 


Cross Reference: 


previously existed in the project database, the Project Manager will 
merge all submitted modules with the existing one, resolving any 
conflicts. CAPS will update the version number. If an existing 
module is submitted to the Project Manager, CAPS will verify that 
all other modules that it depends on are the most up to date 
version. CAPS will generate an alert if there is an error in 
transmitting a module and an acknowledgement if there is no error. 
Functions: R1.19, R1.20, R3.1, R3.3, R3.4, R3.6, R4.3, R4.4, R4.6, 
R4.7, R4.8 

U11. Manage reuse database changes 

User, Software Librarian 

primary 

User submits a new module, or an existing one that was modified, 
to the Software Librarian. When the Software Librarian accepts the 
module for inclusion in the reuse database, a version control 
number is assigned or updated as necessary and the module is 
saved to the reuse library. If the module was an update of an 
existing one, all users of the old version are alerted. The Software 
Librarian can also delete modules. 

Functions: R1.22, R1.23, R3.1, R3.3, R3.4, R3.6 
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Use Case: 


Actors: 

Type: 

Overview: 

Cross Reference: 

Use Case: 

Actors: 

Type: 

Overview: 

Cross Reference: 

Use Case: 

Actors: 

Type: 

Overview: 

Cross Reference: 

Use Case: 

Actors: 

Type: 


U12. Add user to project access 

Project Manager 

secondary 

The Project Manager grants a user access to a specific project. 
Functions:R2.3 

U13. Delete user from project access 

Project Manager 

secondary 

The Project Manager deletes a user's access to a specific project. 
Functions: R2.4 

U14. Add user to the reuse database 

Software Librarian 

secondary 

Upon receiving request, Software Librarian will add user to the 
reuse database access list. 

Functions: R2.1 

U15. Delete user from the reuse database 

Software Librarian 

secondary 
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Overview: Upon receiving request, Software Librarian will delete user from the 

reuse database access list. 

Cross Reference: Functions: R2.2 

Use Case: U16. Exit project 

Actors: User 

Type: primary 

Overview: The user exits the current project. If unsaved data exist, CAPS will 

ask the user if they want to save the data before exiting the project. 
Cross Reference: Functions: R1.18. R1.20 

Use Case: U17. Log off 

Actors: User 

Type: primary 

Overview: User request to log off from the current session of CAPS. If 

unsaved data exist, CAPS will ask the user if they want to save the 
data before logging the user off CAPS and quitting the current 
session of CAPS. 

Cross Reference: Functions: R1.18, R1.20 

3. Expanded Uses Cases 

The expanded use cases are detailed in Appendix A. They are: U3. Open 
project: U4. Modify prototype; U5. Retrieve component from reuse database; U7. Modify 
GUI for displaying prototype execution; U8. Generate executable prototype; 
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U9. Execute the prototype; U10. Manage project changes; U11. Manage reuse 
database changes. 

4. Conceptual Diagrams 

The list of components used in the conceptual diagrams is shown below in Table 
3.8 and the detailed subsections are shown in figures 3.1 through 3.5. The complete 
descriptions of the relations and concepts are included In the detailed views. 


Table 3.8 Conceptual Diagram Components 


Access List 

Alert 

CAPS 

CAPS Graphical Interface 

CAPS Menu 

Comment 

Compiler 

Component 

Constraint 

Editor 

Error 

Executable Code 

GUI Builder 

Host System 

List of Possible Matches 

Network 

Persistent Storage 

Project 

Project Database 

Project Manager 

Prototype 

Prototype GUI 

PSDL Code 

PSDL Data Stream 

PSDL Diagram 

PSDL Object 

Query 

Remote Site 

Requirement 
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Table 3.8 Conceptual Diagram Components (continued) 

Reuse Library _ 

Reuse Library Search _ 

Scheduler _ 

Search Parameters _ 

Software Librarian _ 

Source Code _ 

Stakeholder _ 

System being Designed _ 

System Parameters _ 

Text Box _ 

Translator _ 

User __ 

Work Station 
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Figure 3.1 Conceptual Diagram - Network Support 
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Figure 3.2 Conceptual Diagram - Reuse Support 
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Figure 3.3 Conceptual Diagram - Management Support 
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Figure 3.4 Conceptual Diagram - Execution 
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Figure 3.5 Conceptual Diagram - User Inputs 
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IV. ARCHITECTURAL DESIGN FOR CAPS IN A DISTRIBUTED NETWORK 

The choices for how to design the architecture for a distributed CAPS fall along 
an unbroken continuum. At one end you have dumb client machines and a super smart 
server that does all the work and returns the results to the clients for display to the user. 
On the other end of the spectrum you have a set up that resembles most Local Area 
Networks (LAN) where the server simply provides a service, such as file downloads, 
and the client machines do all the work. The first is highly centralized and the second 
highly decentralized. We believe that the most optimum solution is a client-server 
architecture that falls in-between the extremes of this continuum. The rapid growth in 
the amount of bandwidth available on all kinds of networks, including the Internet, make 
sophisticated client-server architectures very feasible. 

A. DEFINING THE CAPS CLIENT-SERVER ARCHITECTURE 

Any design must take advantage of the increasing power of today’s desktop 
personal computers (PC). By moving a significant load from the server to the client 
machines, you can dramatically improve scalability by reducing the amount of work the 
server must do and the quantity of data it must send to client machines. However, the 
implementation of this client-server architecture should not be limited to just one type of 
PC. Indeed, client machines do not necessarily have to even be a PC. They could, for 
instance, be a UNIX workstation. This diversity reflects the reality of most networks 
today. They are becoming more and more heterogeneous. The internet is the ultimate 
example of this heterogeneity but by no means the only example. The Heterogeneous 
Systems Integrator (HSI), which contains a PSDL graphical editor, written by llker 
Duranlioglu [DURA99] provides an important first step in creating a powerful CAPS 
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client that any truly successful distributed CAPS design will require. The HSI is an all 
Java implementation. 

1. A Three Tier Client-Server Design 

A robust three tier design is the preferred way to implement a distributed CAPS 
in the client-server model. The three tier design offers several advantages over the 
older two tier model. First, it more closely resembles the object oriented paradigm 
practiced today. You can encapsulate the functionality of the client-server design easily 
in a three tiered model and as long as the interfaces between each tier remain 
unchanged, you can update the separate parts independently. The three tiers in a 
distributed CAPS are the client side, represented by the HSI, the communication server 
that communicates with multiple clients over a network and the ‘back end’ programs that 
do the actual work requested by the clients on the computational server. Additionally, 
by carefully allocating responsibilities in the design you can noticeably improve 
performance and latency by ensuring good load balancing. Thus, no particular node 
becomes a bottleneck. 

2. Component Responsibilities 

One of the first questions to resolve in designing a distributed system, is who will 
be responsible for maintaining state information. This can be quite complicated and 
introduce large inefficiencies if it is done at one central location, i.e., on the server side 
of the network. Thus, we decided that the best approach was for each client to maintain 
their own state information. Fortunately, this does not introduce very much additional 
complexity to the HSI already written. The HSI already manages threads that are 
created by opening prototypes and editors. It is a relatively simple matter for the HSI to 
include state information whenever it invokes services from the server. This allows the 
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server to focus on facilitating requests from various clients. If the server 
asynchronously passes client requests off to ‘back end’ for processing, then it can 
continue to efficiently service clients. While the local clients manage their own states, 
one centrally located repository greatly simplifies configuration management and 
version control. Local clients can open prototypes from either local memory or from the 
server side. They can also save to either location. However, the project manager 
controls centrally what changes get into the master copy of a prototype. Thus when 
various clients submit changes to a prototype, they are saved into the user’s centrally 
located folder and the project manager decides when and how to access them. This 
arrangement allows the project manager to easily maintain control over the merging 
process and the resulting configuration and versioning decisions. Users can only read 
the master prototype, and only when the project manager permits it. 

B. IMPLEMENTING THE CAPS CLIENT-SERVER ARCHITECTURE 

There are many ways in which a distributed CAPS could be implemented. The 
first decision is what language, or languages, to use. The original CAPS is written 
largely in Ada, C and C++. Given the realities of writing distributed applications, among 
other considerations, we decided that Java would be a superior language with which to 
implement a distributed CAPS. Choosing an implementation language is only part of 
the total implementation decision. The other part is determining how the 
communications will actually take place in a distributed system. For this, we decided 
that the Object Management Group’s (OMG) Common Object Request Broker 
Architecture (CORBA) offered the best possible solution. Our reasons for these 
selections are detailed below. 
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1. The Selection of Java 


There are many reasons why Java is the language of choice when implementing a 
distributed application. First, the ease of migrating Java across different machines and 
operating systems is an enormous advantage. As discussed previously, it almost a 
certainty that any distributed system deployed will by necessity be heterogeneous. 
Every major type of computer and operating system today has a Java Virtual Machine 
(JVM) written for it. This allows Java byte code written on one type of machine to 
execute on any machine that has a JVM. This was shown to work while implementing 
our proof of concept demonstration. Byte code that was created in a Windows NT PC 
environment was copied to a Sun Solaris Unix machine and successfully executed 
without any alterations. This type of portability will greatly simplify implementing a 
distributed CAPS. Secondly, Java was created as language to operate on the Internet 
and World Wide Web (WWW). Thus it possesses many built-in capabilities that 
facilitate network operations. Additionally, Java has facilities for things such as multi¬ 
threading, garbage collection and error management designed into the language that 
appreciably reduce the difficulty of designing an application. Lastly, as will be 
discussed, Java is a natural fit with CORBA and the two are quickly merging in the 
world of network applications. 

2. The Selection of CORBA 

CORBA provides many advantages over other competing middleware solutions. A 
review of CORBA will facilitate a discussion of these advantages. 
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a. 


CORBA Description 


As previously discussed, it is assumed that a distributed CAPS must 
perform in a heterogeneous environment. While heterogeneity in itself is not negative 
and may, in fact, be viewed as an asset to be leveraged, it does present challenges to 
us as software developers desiring to implement an application in a heterogeneous 
networked system. Heterogeneity creates the need for middleware that can enable the 
sharing of objects, functions and types without causing extensive software re-work for 
developers, or complex work-arounds for users. 

The Object Management Group (OMG) was formed in 1989 to develop, 
adopt, and promote standards for the development and deployment of applications in 
distributed heterogeneous environments. Since that time, the OMG has grown to be the 
largest software consortium in the world, and has developed the Object Management 
Architecture (OMA). The OMA consists of an Object Model and a Reference Model. 
The Object Model defines how objects can be described, and the Reference Model, 
shown in Figure 4.1, deals with interactions between those objects. In the Object 
Model, clients issue requests for services to objects (much like a remote procedure call 
(RPC)). The implementations of these objects are hidden from the client. A key 
component of the Reference Model is the Object Request Broker (ORB), which 
facilitates communication between clients and objects. CORBA is the specification 
developed by the OMG that details the interfaces and characteristics of the ORB. In 
CORBA the terms “client” and “server” are not rigidly defined roles. The CAPS server 
could handle the request from client machines and in turn become a client itself when it 
invokes requests on some ‘back end’ implementation. 
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Figure 4.1 OMG Reference Model Architecture From [SCHM99] 

In CORBA, an application consists of one or more objects that may reside 
on the same or different platforms. An object provides service(s) that can be 
“requested” by a client. Clients obtain services from an object by making “requests” that 
consist of an operation, the name of the object that will respond, zero or more 
parameters, and an optional request context. The object may or may not return results 
to a client, and will return an exception if an abnormal condition occurs. Object 
implementations may be written in a variety of languages and may exist in a variety of 
forms. Essentially, CORBA allows components to discover each other and interoperate 
on an object bus. However, CORBA does much more than just create a simple object 
bus, as shown In Figure 4.2. It also provides an extensive set of services for such 
things as creating and deleting objects, accessing them by name, putting them in 
persistent storage, externalizing their states and forming ad hoc relationships between 
objects. Thus you can design an ordinary object and then give it the specific 
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characteristics needed for a distributed application by using CORBA’s multiple 
inheritance. [ORFA98] 





OEB-specdfic interface 


(~) STANDARD PROTOCOL 


Figure 4.2 CORBA ORB Architecture From [SCHM99] 

Methods can be invoked statically or dynamically. In Static invocation, a 
client’s request is made via interface definition language (IDL) “stubs” on the client side, 
and the response is handled by IDL “skeletons” on the object side. The stubs and 
skeletons interface with the CORBA ORB. In Static Invocation, the IDL Client Stub 
converts data from the client’s local data representation (type) to the Common Data 
Representation (CDR), which is platform and language independent. On the object’s 
platform, the Object Skeleton executes the reverse operation. In Dynamic Invocation, 
requests are made via Dynamic Invocation Interface. With Dynamic Invocation the 
developer is afforded more flexibility. In Dynamic Invocation, the Dynamic Skeleton 











Interface (DSI) may take the place of the Static Invocation Object Skeleton to 
accomplish data conversion at run time. 

CORBA supports two types of (method) invocation semantics: 
synchronous invocation and asynchronous invocation. Synchronous invocation is 
blocking. The client will invoke the method and block until it receives a response from 
the server (object implementation). Asynchronous invocation is non-blocking. The client 
will invoke a method, continue its computation, and collect results as they arrive. With 
non-blocking primitives, the SEND primitive returns control to the requesting program as 
soon as the message is copied from the user buffer to the kernel buffer. The 
corresponding object that executes the RECEIVE primitive signals its intention to 
receive a message, provides a buffer into which the message will be copied and 
continues to execute. [POPE98] 

Through the IDL stubs, a client can use RPC-style semantics 
(synchronous), or by using Dynamic Invocation Interface (Dll) a client can use 
SEND/RECEIVE semantics. Using Dll allows a client to directly access the underlying 
request mechanisms provided by the ORB. Applications use Dll to dynamically issue 
requests to objects without requiring IDL stubs to be linked in. The Dll allows clients to 
make non-blocking “deferred synchronous” (separate SEND and RECEIVE operations) 
and one way (SEND only) calls. [POPE98] 

Many industry leaders, including IBM, Novell, BorlandA/isigenic, SunSoft, 
Netscape, Oracle and JavaSoft just to name a few, have recognized the importance of 
CORBA middleware in realizing the potential of heterogeneous, distributed 
systems[ORFA98]. In fact, CORBA is now part of the Defense Information 
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Infrastructure Common Operating Environment (Dll COE) standard web browser, and is 
finding increasing use in Department of Defense applications. The utility of CORBA 
lies in its ability to integrate diverse applications across a variety of networks and 
network protocols. CORBA’s language independent IDL’s allow objects to be used from 
a variety of programming languages, including COBOL. C, C++, Ada, Smalltalk, Perl 
and Java. CORBA-based applications are independent of network protocols so they 
may be run in a distributed system over a diverse network. These attributes ensure 
CORBA’s tremendous usefulness in a heterogeneous environment. 

b. CORBA Advantages for a Distributed CAPS 

CORBA certainly is not the only solution for implementing an application in 
a distributed environment. The other prominent options include legacy solutions that 
predate the ORB concept such as Java sockets. Common Gateway Interface (CGI) 
scripts with Hypertext Transfer Protocol (HTTP) and Java Servlets. Non-CORBA ORBs 
are JavaSoft’s Remote Method Invocations (RMI) and Microsoft’s Distributed 
Component Object Model (DCOM). As for simple performance metrics, the fastest 
implementation for operating over a network is a socket using a buffered data stream. 
However, as we’ll discuss below, this is not a realistic choice for implementing a 
distributed CAPS. The three ORBs, CORBA, DCOM and RMI, are very close in 
performance and as a group are a little less than twice as slow as a socket. Servlets 
are well over an order of magnitude slower than a socket and the CGI/HTTP 
combination is well over two orders of magnitude slower. [ORFA98] 

The three legacy solutions all suffer from the fact that they operate at very 
low levels of abstractions. Sockets in particular are a relatively primitive model. 
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Sockets are ‘close to the wire’ in the sense that they are the lowest level of abstraction 
available. This accounts for their efficient performance but it also makes them difficult 
to program. The other solutions build upon sockets as a transport mechanism while 
shielding users from having to deal with the details of socket programming. CGI scripts 
over HTTP is the current predominant model for three tiered applications over the 
internet. HTTP provides simpler semantics on top of sockets which CGI scripts use to 
communicate between clients, servers and ‘back end’ resources. However, besides 
being incredibly slow, other disadvantages include a lack of typed parameter support 
and object reference persistence, a relatively low level of abstraction and poor 
scalability. A Servlet is a small piece of Java code loaded onto a server. It operates 
much as CGI but it overcomes some of the worst performance degradations by 
remaining in memory between request and by staying connected to ‘back end’ 
resources. As with CGI though, the lack of typed Interfaces result in a proliferation of 
interfaces as the number of methods grows and each method must be prepared to 
marshal and unmarshal multiple data types. 

RMI and DCOM share many of the advantages of CORBA for developing 
distributed applications. There are however, some significant drawbacks to both. RMI 
and DCOM both lack the comprehensive services and facilities that are available for 
CORBA. These include a Naming Service, Event Service, Property Service, 
Relationship Service, Lifecycle Service, Security Service and a continually growing host 
of CORBA facilities such as mobile agents, data interchange, workflow, firewalls and 
business object frameworks. The ultimate goal of CORBA facilities is to provide an IDL 
interface for virtually every networked service. RMI is an all Java implementation, which 
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could potentially become a problem at some point in the future. It is also proprietary 
and thus doesn’t interact with other ORBs. The extremely proprietary nature of DCOM 
is certainly it’s biggest disadvantage. Microsoft only produces Window versions of 
DCOM and in addition, it must run in their JVM. There are some third party attempts at 
porting it to other platforms, but so far these have met with limited success. Even if 
successfully ported, there exist deficiencies in the design of DCOM which make it 
inferior to CORBA. It does not follow the object oriented model since it precludes 
inheritance. There are work-arounds but they can be cumbersome. Also, object 
references are not persistent and due to the limitations of working only on Window 
platforms, it is not scalable. 

In light of the discussion, it becomes clear that CORBA addresses many 
of the issues we initially identified as pertinent to developing a distributed CAPS. With 
CORBA, the type of network becomes irrelevant to the operation of a distributed CAPS. 
Indeed, the proof of concept implementation done for this work started on a single PC 
and then migrated seamlessly to first an all PC environment and then to one where the 
client resided on a PC and the server on a Sun Solaris Unix. The next step, to operate 
over the internet, would be just as smooth a transition. Clearly, the heterogeneous 
nature of any large network becomes immaterial given the fact that every important 
language has an IDL mapping and every major type of operating system supports 
CORBA. The fact that no special hardware is required is also a plus. CORBA’s 
extensive support for exceptions and the ability to implement user defined exceptions 
provide for greatly improve fault tolerance. Despite the intuitive feeling that the 
overhead of CORBA must be significant, it is actually shown to be quite acceptable. 
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With the introduction of real-time CORBA this year, latency should become even less of 
an issue. Lastly, the CORBA services and facilities provide extensive support for 
cu rrent and futu re growth. 
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V. A DISTRIBUTED CAPS PROOF OF CONCEPT IMPLEMENTATION 

The primary objective in the initial implementation was to demonstrate the 
efficacy of a distributed CAPS design using Java and CORBA. The first step in this 
process was completed with the HSI which was written in Java and included a PSDL 
editor. There was, however, little other functionality built into the initial HSI. Our goal 
was to create an implementation where the HSI would run on a PC and remotely invoke 
methods on a CAPS server located on a Sun Solaris Unix machine. The mechanism for 
these invocations would be CORBA. Since this was a proof of concept implementation, 
only selected functionality was demonstrated in order to prove the effectiveness of the 
Java/CORBA combination before attempting large scale development. 

A. PRODUCT CHOICES FOR IMPLEMENTATION 

There are many possible environments for developing Java code and currently 
there are three major suppliers of CORBA/Java ORBs. In selecting an environment for 
developing Java code, the continuum runs from using the Java Developer Kit (JDK) 
supplied by JavaSoft and a text editor which are a very minimalist approach to full 
feature, comprehensive integrated development environments (IDE). Java IDEs are 
offered by a host of vendors. We decided to use the newest version of the JavaSoft 
JDK, 1.2.2. There were several reasons for this. First, the JDK is supplied free of 
charge. Secondly, in keeping with the walk before running philosophy, choosing the 
JDK gave us a simpler, more straightforward design environment. It allowed us to 
concentrate on creating a distributed CAPS without the distraction of all the bells and 
whistles that accompany the more feature laden IDEs. The documentation with the JDK 
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is also very comprehensive. As v\/ill be discussed below, the JDK has one additional 
advantage - a built-in Java ORB that is fully CORBA compliant. 

The three Java ORBs available today are JavaSoft’s JAVA IDL, Iona’s OrbixWeb 
3.0 and BorlandA/isigenic’s VisiBroker for Java 3.1. Much of the same reasoning for 
selecting JavaSoft’s JDK for writing the Java code went into the selection of using 
JavaSoft’s Java IDL for the ORB in our implementation. While far from a full feature 
ORB (it lacks such things as a non-volatile Naming Service and many of the add-on 
services) it is fully CORBA compliant. In our case, the simpler ORB was more a benefit 
than a disadvantage. As a distributed CAPS moves from the research stage to a 
production release, the work done can be easily migrated to a more full feature ORB. 
Also, it is very likely that JavaSoft will continue to improve the Java IDL and such a 
migration may not even be necessary. Java IDL is already built into the JDK 
environment. We did discover that some bugs exist in versions of JDK before 1.2.2 
which prevented the Java IDL from operating properly. The IDL to Java compiler 
worked correctly but using a version earlier than 1.2.2 resulted in exceptions when 
attempting to connect to the ORB. 

B. IMPLENTATION DECISIONS 

The HSI, as implemented by [DURA99], provided the GUI by which a user could 
create a prototype with the graphical editor and generate the corresponding PSDL code. 
It could open from and save to a local memory location or the user’s allocated memory 
storage location on a network. The entire process was one controlled by the current 
instantiation of the HSI created by the user. In order to demonstrate the viability of a 
distributed CAPS operating in a client-server paradigm, we had to separate out some of 


62 



the functionality into distinct client and server processes. Additionally, we wanted to 
incorporate some of the tasks from the original stand-alone CAPS into our client-server 
designed one. The IDL file and the two files that implement the server are listed in 
Appendix B. The files generated by the IDL-to-Java compiler are listed in Appendix C. 
The HSI files that were modified to implement the remote calls to the server are listed in 
Appendix D. All three appendixes include both source files and the corresponding 
Javadoc generated documentation. 

First, we decided that the user should be able to open an existing prototype from 
either the local memory or from prototypes stored on the server side of the network. 
The user was also given the ability to save files on the server side as well as in his/her 
own memory space as before. This remote save was implemented as the commit 
function of the HSI. We decided to incorporate execution of the translate function on 
the server side in order to further extend the work began in [DURA99]. When a user 
selects the translate function during a HSI session, the current prototype file is 
transferred to the server where the translate is actually invoked. The Ada files 
generated are stored on the server in the user’s directory and a message notifying the 
user of a successful translate is sent to the HSI. Likewise, the user is notified after a 
prototype’s PSDL file is successfully saved to the server side when the user invokes the 
commit function from the HSI. On the server side, when the translate function is 
invoked, a shell script is called which performs the actual translating. This is not a true 
three tier design but as the primary objective was to test the communication between 
the HSI and a remotely located server, it was acceptable. As this research matures, it 
may be that ultimately the server communicates with the ‘back end’ implementation 
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doing the actual work over a second CORBA object bus. In essence, the server would 
become the client in a client-sen/er relationship with the ‘back end’ implementation. 

The interfaces of the methods needed to implement this initial design were 
described in CORBA IDL and compiled using the IDL-to-Java compiler in JDK 1.2.2. 
When invoking the IDL-to-Java compiler, the command line argument -fno-cpp is used 
in order to disable the C++ preprocessor that is defaulted enabled. This preprocessing 
is not needed and prevented the IDL-to-Java from performing properly in the lab. The 
result were 15 .Java files which represented all the classes required to implement the 
interfaces described in the initial IDL description. The corresponding .class files were 
created by the JDK 1.2.2 Java compiler. The files were responsible for the actual 
operation of the CORBA object bus by marshalling and unmarshalling data being 
passed over the network between the client HSI and the server side. Additionally, they 
provide stub and skeleton implementations containing all the necessary information for 
proper communications with the ORB. They simply had to be extended and the 
desired functionality added, e.g. saving or translating a file, and they were ready to be 
compiled into .class files by the Java compiler. 

Since this was a proof of concept demonstration, robustness, ease of use and 
efficiency were not primary considerations. Minimal error checking, such as ensuring 
that a prototype was opened in the HSI before invoking the translate function on the 
server, was incorporated. However, other than the built in mechanisms such as type 
checking, not much work was done in this area. Given the effectiveness of Java 
exceptions and the ease of creating user defined exceptions in CORBA, this will not be 
an impediment to future work. Likewise, three pieces of information are currently 
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entered on the command line when starting the HSI or the server. On starting the HSI, 
PROTOTYPEHOME and CAPSUser tell the system where the prototype PSDL files are 
located and who the current user is. In the event that PROTOWPEHOME is not 
entered, the system will look in the user’s home directory as a default. Again, the default 
is to the home directory of who ever starts the CAPS server. These could easily be 
incorporated into the respective GUIs in future work. 

The sequence of events that brings the entire system on line are quite 
straightforward. First, on the machine that is hosting the server, start the naming 
service. Second, in another process, e.g., a separate DOS window, start the server 
implementation. Third, start the HSI on another machine (it can be started on the same 
machine in a third process). For all three, you must include the desired communication 
port. It must be the same for three processes. Additionally, for the client HSI you must 
include the internet location of the host running the server. More advanced 
implementations can eliminate these requirements. The following are examples of the 
actual semantics needed. To invoke the naming service, use “tnameserv 
-ORBInitialPort 1050.” For the server, use “java 

DCAPSJavaHome=$CAPSHOME\.caps CapsServer -ORBInitialPort 1050”. Lastly, for 
the HSI use “java -PROTOTYPEHOME=\jdk2\.caps - DCAPSUser=kreeger caps.Caps - 
ORBInitialHost 131.120.8.58 -ORBInitialPort 1050”. 
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VI. CONCLUSIONS AND FUTURE WORK 

Our initial tests are very encouraging. We were able to easily integrate the 
existing Java HSI running on a Windows NT machine into a client-server arrangement 
with the server running on a Sun Solaris Unix machine. We successfully created 
prototypes in the graphical editor of the HSI and saved the resulting PSDL files both to 
the HSI’s memory and transferred it over the network, where the server stored in its 
memory. We successfully opened PSDL files from both locations and displayed them in 
the graphical editor. Additionally, we sent PSDL files over the network to the server 
where they were translated and the corresponding Ada files generated. Thus, there 
appears to be little doubt about the ability of the current CAPS to be implemented in a 
client-server design that functions over any size network, including ultimately the 
Internet. The machinery that makes this not only possible, but even a reasonable effort, 
is CORBA. CORBA makes it feasible to convert the current CAPS to a client-server 
architecture while preserving much of the existing codebase. It is straightforward to 
instantiate a CAPS object on the server and then send a reference object to the CAPS 
object to any client. The users on the client side interact with the HSI’s extremely 
intuitive interface and whenever they need CAPS functionality, such as translate, the 
HSI simply invokes the method on the CAPS object reference that was received from 
the server. Thus much of the more complicated code that has been developed for the 
stand-alone CAPS can continue to be used. To this code, the origins of the request are 
irrelevant. As long as the proper parameters are passed in, the expected result will be 
produced and where the result is ultimately sent doesn’t matter. This arrangement 
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allows the HSI to manage the user inputs to a prototype design locally. This is a very 
efficient manner for this type of operations. The more heavy duty, less frequently 
invoked functionality can reside on the server side of the network. The additional 
benefit of this design is that as more effective means of executing these services are 
implemented or additional requirements are discovered, it is a much simpler matter to 
update the single copy of the code located on the server side compared to trying to 
update code on a variety of different client machines across an entire network. As long 
as the interfaces remain unchanged, any alterations in one tier of the architecture will 
remain transparent to the other tiers. 

As for the future, much remains to be done in order to fully realize the potential of 
a distributed CAPS. The work done thus far has clearly shown the potential that exists. 
However, to become a practical system for creating and managing prototyping for large 
software projects, a distributed CAPS must be fully functional and much more robust 
than at present. The next logical phase of this research should focus on two parallel 
tracks. 

On the HSI the effort should concentrate on implementing the rest of the existing 
functionality for the current CAPS and on engineering production quality robustness into 
the HSI. The implementations of the commit and translate functions In this work provide 
an example of how to invoke from the HSI existing CAPS methods on a CAPS server 
and return the results to the HSI. Incorporating additional methods into the IDL 
interface definition and recompiling it are straightforward processes. This will produce 
the files necessary to implement the additional methods on the server side and the HSI. 
The second part of the effort for improving the HSI is easily done concurrently with the 
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first part. As additional methods are included into the HSI, every effort should be made 
to ensure production quality robustness. The ease of creating user defined exceptions 
in both Java and CORBA simplify this effort tremendously. 

In parallel with the HSI work, there remain tasks to be completed on the CAPS 
software. First, while comprehensive theoretical work has been done on every aspect 
of CAPS, there remains functionality that either needs to be completed or enhanced. 
This is especially true in regards to the reusable database. Finishing this work in 
conjunction with the HSI work provides the opportunity to tightly coordinate efforts. 
Secondly, the CAPS method implementations should be separated out from the CAPS 
server. This would allow the CAPS server to be as efficient as possible and easily scale 
to a larger number of users. Furthermore, by isolating the actual method of 
implementations from the CAPS server, they can be modified and updated more easily. 

In conclusion, the endeavor to deploy a distributed CAPS is both feasible and 
necessary. The emergence of the Java/CORBA technology supplies the means by 
which migrating CAPS from an isolated system to a fully functional distributed system 
becomes not just possible, but quite manageable. That is fortunate timing, for if CAPS 
is to continue to be a driving force in software engineering research it must adapt to the 
new realities of a networked world. 
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APPENDIX A: EXPANDED USE CASES 


Selected used cases are detailed below in expanded format: 


Use Case: 

Actors: 

Type: 

Purpose: 

Overview: 


Cross Reference: 


U3. Open project 

User 

primary and essential 
Allow user to open a project 

After logging into CAPS, user can select an existing project and 
open it, if he has the proper authorization from the project manager. 
If the user has project manager privileges, they can open a new 
project. 

Functions: R2.3, R4.2, R4.3 

Use Cases: User must have completed the Start-up and Log in use 
cases 


Section: Main 

Typical Course of Action 

Actor Action System Response 

1. This use case begins after the user 
has successfully started and logged 
into CAPS 

2. The user chooses to open a new or 
existing prototype 
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a. If the user chooses a new 
prototype, see section Open New 
Prototype 

b. If the user chooses an existing 
prototype, see section Open Existing 
Prototype 

Section: Open New Prototype 

Typical Course of Action 
Actor Action 

1. The user selects the new prototype 
option 

4. The user inputs new prototype 
information 

Section: Open Existing Prototype 
Typical Course of Action 
Actor Action 

1. The user selects the open existing 
prototype option 

3. The user highlights the desired 
prototype and selects to open it 


System Response 

2. The system verifies the user has 
project manager level privileges. 

3. The system prompts the user for 
new prototype information 

5. A new prototype is created 


System Response 

2. System presents the user with a list 
of existing prototypes within a file 
structure that can be navigated 
4. The selected prototype is loaded at 
the users workstation 
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U4. Modify prototype 

User 

primary and essential 
Allow user to modify a prototype 

After opening a prototype, the user will be able to make changes to 
the graphical interface of the control flow diagram or to the text 
boxes associated with either objects or data streams in the 
diagram. These changes will be automatically reflected in the 
PSDL code. The user can record user comments, stakeholder 
comments and requirements for the system being prototyped. 
Additionally, the user can directly access the PSDL code and 
change it manually. 

Cross Reference: Functions: R1.1, R1.2, R1.3, R1.4, R1.5, R1.6, R1.7, R1.21, R4.4, 
R4.5 

Use Cases: User must have completed the Start-up, Log in and 
Open Project use cases 

Section: Main 

Typical Course of Action 

Actor Action System Response 

1. This use case starts after the user 
has opened a prototype 


Use Case: 

Actors: 

Type: 

Purpose: 

Overview: 
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2. The user can make changes 
graphically or textually to the control 
flow diagram or may edit the actual 
PSDL code 

a. If user makes graphical changes, 
see section Graphical Changes 

b. If user makes textual changes, see 
section Textual Changes 

c. If the user edits the PSDL code, 
see section Edit PSDL Code 

Section: Graphical Changes 
Typical Course of Action 

Actor Action System Response 

1. User selects graphical input from the 2. The changes made by the user are 
menu of inputs, such as circle or line, displayed In the diagram and the PSDL 
or selects an existing graphical code in main memory is generated 
representation within the control flow and/or modified 
diagram and manipulates it within the 
diagram 
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Section: Textual Changes 

Typical Course of Action 
Actor Action 

1. The user chooses an existing 
graphical object from the control flow 
diagram and selects to add textual 
input to it 

3. The user makes the desired 
changes to the textual input box and 
confirms done when the input is 
completed 

Section: Edit PSDL Code 

Typical Course of Action 
Actor Action 

1 The user selects the option to directly 
edit the PSDL code from a CAPS menu 
3. The user makes changes to the 
PSDL code and selects save or closes 
the editor when done 


System Response 

2. The text box for the graphical object 
selected is displayed 

4. The text box is no longer displayed, 
the changes are accepted, the PSDL 
code is generated and/or modified in 
main memory and if applicable the 
diagram presentation is modified 


System Response 

2. The PSDL code for the prototype is 
displayed within a text editor 

4. The PSDL code is modified in main 
memory 

5. The modified PSDL code is 
validated for correctness before the 
user can exit the text editor 


75 


Use Case: 

Actors: 

Type: 

Purpose: 

Overview: 


Cross Reference: 


U5. Retrieve component from reuse database 

User 

primary and essential 

To retrieve reusable components from library 
The user accesses the reuse database and inputs search 
parameters. CAPS responds with no match, unique match or a list 
of possible matches. CAPS generates an alert if there is an error in 
transmission and an acknowledgement if the transfer is successful. 
Functions: R1.21, R3.2, R3.4, R3.6 

Use Cases: User must have completed the Start-up, Log in and 
Open Project use cases 


Section: Main 

Typical Course of Action 
Actor Action 

1. The user selects option from CAPS 
menu to retrieve component from 
reusable component library 


3. The user inputs 

the 

desired 

component parameters 

and 

selects 

retrieve 




System Response 

2. An input box is displayed for the user 
to input the desired parameters of the 
component to be returned 

4. The parameters are sent to the 
reuse component library, possible over 
a network to a remote site 

5. The parameters are accepted, a 
query formulated and the reuse 
component library searched 
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7. The user selects the desired 6. The user is informed that there was 
component, if one available a match, multiple possible matches or 

no match 

8. A copy of the selected component is 
returned to the user 

9. The user is notified that the transfer 
was successful 


Alternate Courses 

• Line 9. If the transfer is unsuccessful, the user is notified. The type of error is 
displayed, if known 


Use Case: 
Actors: 

Type: 

Purpose: 

Overview: 

Cross Reference: 


U7. Modify GUI for displaying prototype execution 
User 

primary and essential 

To modify the GUI generated to display prototype functionality 

User selects and then edits the files that provide functionality for 

displaying prototype execution 

Functions: R1.4, R1.5, R1.6, R1.7, R1.8, R1.9 

Use Cases: User must have completed the Start-up, Log in and 

Open Project use cases and have completed the Generate 

Executable Prototype use case sometime previously (not 

necessarily the same session) 
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Section: Main 


Typical Course of Action 

Actor Action System Response 

1. This use case starts after the user 
has opened a prototype 

2. The user can make changes to the 
source code to affect prototype 
functionality or to the prototype 
graphical interface 

a. If user makes functionality 
changes, see section Functional 
Changes 

b. If user makes graphical interface 
changes, see section Interface 
Changes 

Section: Functional Changes 

Typical Course of Action 
Actor Action 

1. The user selects the edit source file 
option from a CAPS menu 


System Response 

2. A list of normal programming source 
files (e.g. Ada or Java) within the 
current prototype is displayed 
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3. The user selects the source file to 
edit 

5. The user makes changes to the file 

6. The user saves the file 

8. The user quits the file 

9. The user quits the editor 


Section: Interface Changes 
Typical Course of Action 
Actor Action 

1. The user selects the edit interface 
option from a CAPS menu 

3. The user makes the desired 
changes to the prototype GUI 

4. The user selects the generate code 
option from the GUI builder 

6. The user saves the file(s) 

8. The user quits the GUI builder 


4. The selected file is opened in a text 
editor 

7. The file is written to persistent 
storage 

10. The user is queried about saving 
any unsaved changes, which will be 
saved to persistent storage and the 
editor is closed 

System Response 

2. A GUI builder is invoked with the 
current prototype GUI opened 

5. Source code for the prototype GUI, 
which is controlled by the CAPS 
generated control source code, is 
automatically generated 

7. The file(s) is written to persistent 
storage 
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Use Case: 

Actors: 

Type: 

Purpose: 

Overview: 


Cross Reference: 


U8. Generate Executable Prototype 
User 

primary and essential 
Prepare a prototype for execution 

The user translates the prototype in order to create source code in 
an implementation language from the PSDL and link it. The user 
will then verify through CAPS that all static hard real time 
constraints are met. The user will then compile the prototype 
source code. 

Functions: R1.9, R1.10, R1.11 

Use Cases: User must have completed the Start-up, Log in and 
Open Project use cases 


Section: Main 

Typical Course of Action 
Actor Action 

1. The user selects the translate option 
from a CAPS menu 

3. The user selects the schedule option 
from a CAPS menu 

5. The user selects the compile option 
from a CAPS menu 


System Response 

2. PSDL code for prototype is used to 
generate 3'’'‘ generation object oriented 
language source code 
4. All static hard real time constraints 
are verified as met 

6. All source files are compiled and 
executable files created 
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Alternate Courses 


• Line 4. Some static hard real time constraint is missed. CAPS generates an alert for 
the user. 


Use Case; 

Actors: 

Type: 

Purpose: 

Overview: 


Cross Reference: 


U9. Execute the prototype 

User 

primary and essential 

Execute the prototype and perform analysis of system constraints 
The user will execute the prototype. As the user test the prototype 
functionality, CAPS will verify that all dynamic hard real time, 
concurrency and network constraints are met. CAPS will allow the 
user to record stakeholder and/or user comments. 

Functions: R1.1, R1.2, R1.3, R1.12, R1.13, R1.14, R1.15, R1.16 
Use Cases: User must have completed the Start-up, Log in and 
Open Project use cases and have completed the Generate 
Executable Prototype use case sometime previously (if not 
immediately after generating the executable prototype, you may 
execute a prototype that doesn’t have the most recent changes) 
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Section: Main 


Typical Course of Action 
Actor Action 

1. The user selects the execute option 
from a CAPS menu 

3. The user test the functionality of the 
designed system with manual inputs or 
scripted tests 


7. The user selects the record 
comments option from a CAPS menu 

9. The comments are entered and the 
comment entry box deselected 


System Response 

2. The prototype GUI interface is 
generated and execution of the system 
being designed begins 

4. Dynamic hard real time constraints 
are verified met 

5. If the designed system is multi¬ 
threaded, concurrency constraints are 
verified met 

6. If the designed system is distributed, 
network constraints are verified met 

8. A menu is displayed that allows the 
choice of selecting user or stakeholder 
comment inputs 

10. The comments are saved to 
persistent storage and become part of 
the project record 


Alternate Courses 

• Line 4. Dynamic hard real time constraints are not met. CAPS generates an alert for 
the user. 
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• Line 5. Concurrency constraints are not met. CAPS generates an alert for the user. 

• Line 6. Network constraints are not met. CAPS generates an alert for the user. 

Use Case: U10. Manage project changes 

Actors: User, Project Manager 

Type: primary and essential 

Purpose: Allow Project Manager to control configuration and version control 

for a project 

Overview: User (possibly more than one) will submit module(s) to the Project 

Manager for incorporation into the project prototype. The user may 
elect to return the entire prototype after making changes to only 
some of the modules. In this case the Project Manager must 
identify which modules are changed or new. If the module does not 
already exist in the project database, the Project Manager will 
merge the submitted module(s) into one module, resolving any 
conflicts. CAPS will assign and track a version number and insert 
the module into the project database, making ties to all other 
modules that may exist in the project database. If the module 
previously existed in the project database, the Project Manager will 
merge all submitted modules with the existing one, resolving any 
conflicts. CAPS will update the version number. If an existing 
module is submitted to the Project Manager, CAPS will verify that 
all other modules that it depends on are the most up to date 
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version. CAPS will generate an alert if there is an error in 
transmitting a module and an acknowledgement if there is no error. 
Cross Reference: Functions: R1.19, R1.20, R3.1, R3.3, R3.4, R3.6, R4.3, R4.4, R4.6, 

R4.7, R4.8 

Use Cases: Project Manager must have completed the Start-up, 
Log in and Open Project use cases 

Section: Main 

Typical Course of Action 

Actor Action System Response 

1. This use case begins with the 2. All modules submitted for a project 
Project Manager selecting the option that are pending action are displayed 
from a CAPS menu to review modules 
that have been submitted for the 
current project 

3. Project Manager determines module 
update state: 

a. If a single module not previously in 
the project is submitted, see section 
Single New Module 

b. If multiple versions of a module not 
previously in the project are submitted, 
see section Multiple New Modules 
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c. If a single module previously in the 
project is submitted, see section Single 
Old Module 

d. If multiple versions of a module 
previously in the project are submitted, 
see section Multiple Old Modules 

Alternate Courses 

• Line 2. If there was an error in receiving any module, the Project Manager is alerted 
Section: Single New Module 
Typical Course of Action 

Actor Action System Response 

1. The Project Manager selects the 2. The module is displayed in a text 
option to view the new module from a format 
CAPS menu 

3. If the Project Manager decides to 4. The Project Manager is asked where 
include the module in the project, she to save the file and exactly which 
selects the add option from a CAPS project to include it in 
menu 

5. The Project Manager specifies the 6. The module is saved and included 
location to save to and the project into as directed 
which the module is to be included 
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7. The module will be assigned a 
version number automatically 

8. The module will be registered with 
the project automatically 


Section: Multiple New Modules 

Typical Course of Action 
Actor Action 

1. The Project Manager selects the 
option to view the new modules from a 
CAPS menu 

3. If the Project Manager decides to 
include the modules in the project, he 
selects the merge option from a CAPS 
menu 

6. The Project Manager specifies the 
location to save to and the project into 
which the module is to be included 


System Response 

2. The modules are displayed in a text 
format as selected 

4. The Project Manager is asked which 
modules to merge 

5. After merging the modules into a 
single prototype, the Project Manager 
is asked where to save the file and 
exactly which project to include it in 

7. The module is saved and included 
as directed 

8. The module will be assigned a 
version number automatically 
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9. The module will be registered with 
the project automatically 

Alternate Courses 

• Line 5. If the modules cannot be successfully merged automatically, the Project 
Manager Is sent an alert along with information about the conflict(s) 


Section: Single Old Module 

Typical Course of Action 
Actor Action 

1. The Project Manager selects the 
option to view the new module from a 
CAPS menu 

3. If the Project Manager decides to 
replace the existing module In the 
project, she selects the merge option 
from a CAPS menu 

6. The Project Manager specifies the 
location to save to and the project into 
which the module is to be included 


System Response 

2. The module is displayed in a text 
format 

4. The Project Manager is asked to 
specify the modules to merge 

5. After merging the modules into a 
single prototype, the Project Manager 
is asked where to save the file and 
exactly which project to include it in 

7. The module is saved and included 
as directed 
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8. The module will be assigned an 
updated version number automatically 


Alternate Courses 

• Line 3. The Project Manager can elected to simply replace the existing module with 
the new one 

• Line 5. If the modules cannot be successfully merged automatically, the Project 
Manager is sent an alert along with information about the conflict(s) 


Section: Multiple Old Modules 
Typical Course of Action 
Actor Action 

1. The Project Manager selects the 
option to view the new modules from a 
CAPS menu 

3. If the Project Manager decides to 
include the modules in the project, he 
selects the merge option from a CAPS 
menu 


System Response 

2. The modules are displayed in a text 
format as selected 

4. The Project Manager is asked to 
specify the new modules to merge into 
a single module 

5. After merging the modules into a 
single module, the Project Manager is 
asked which existing module to merge 
with the single new module 
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7. The Project Manager specifies the 6. After merging the modules into a 
location to save to and the project into single prototype, the Project Manager 
which the module is to be included is asked where to save the file and 

exactly which project to include it in 

8. The module is saved and included 
as directed 

9. The module will be assigned an 
updated version number automatically 

Alternate Courses 

• Line 4. The Project Manager may elect to merge the new modules and the existing 
module at the same time 

• Line 5. If the modules cannot be successfully merged automatically, the Project 
Manager is sent an alert along with information about the conflict(s) 

• Line 6. If the modules cannot be successfully merged automatically, the Project 
Manager is sent an alert along with information about the conflict(s) 

Use Case; U11. Manage reuse database changes 

Actors: User, Software Librarian 

Type: primary and essential 

Purpose: Allow Software Librarian to control configuration and version control 

for the reuse database 
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Overview: 


User submits a new module, or an existing one that was modified, 
to the Software Librarian. When the Software Librarian accepts the 
module for inclusion in the reuse database, a version control 
number is assigned or updated as necessary and the module is 
saved to the reuse library. If the module was an update of an 
existing one, all users of the old version are alerted. The Software 
Librarian can also delete modules. 

Cross Reference; Functions: R1.22, R1.23, R3.1, R3.3, R3.4, R3.6 

Use Cases: Software Librarian must have completed the Start-up 
and Log in use cases 


Section: Main 

Typical Course of Action 
Actor Action 

1. This use case begins with the 
Software Librarian selecting the option 
from a CAPS menu to review modules 
that have been submitted for inclusion 
in the reuse database 
3. The Software Librarian selects the 
option to view the a module on the list 
from a CAPS menu 


System Response 

2. All modules submitted for inclusion 
that are pending action are displayed 


4. The module is displayed in a text 
format 
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5. After review, the Software Librarian 
selects the add option from CAPS 
menu. 

6. The Software Librarian chooses to 
add the module as a new one or to 
replace an existing module with the 
new one: 

a. If the module is added as a 
completely new one, see section Add 
New Module 

b. If the module is replacing an 
existing module, see section Replace 
Existing Module 

Section: Add New Module 

Typical Course of Action 

Actor Action System Response 

1. The Software Librarian elects to add 2. The module is added to the reuse 
the submitted module as a new module database and a version control number 

is assigned 
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Section: Replace Existing Module 
Typical Course of Action 
Actor Action 


System Response 

1. The Software Librarian elects to 2. The new module replaces the 
replace an existing module with the existing one in the reuse database 
submitted module 3. The version control number is 

updated 

4. Users of the old version are alerted 
that there are changes to the module 
they checked out 
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APPENDIX B: CAPS SERVER IMPLEMENTATION SOURCE CODE 


This appendix contains the IDL file that describes the methods defined in order to 
implement a distributed CAPS server. It also contains the source files and Javadoc 
generated documentation for the CAPS server. 


* The Interface Description Language (IDL) for a Distributed CAPS 

* 

* @author Gary Kreeger 

* @version 1.0 
♦/ 


module DistributedCaps 

{ 

interface DistCaps 

{ 

exception cantWriteFile {}; 
exception cantReadFile {}; 

typedef sequence<octet> prototype_file; 
typedef sequence<string> prototype_iist; 

string translate (in prototype_file psdl__file, in string name, 

in string version, in string user) raises (cantWriteFile); 

prototype_list getjroto list (in string user); 

prototype_file open_j)roto (in string name, in string user) raises (cantReadFile); 

string commit (in prototype_file psdl_file, in string name, 

in string version, in string user) raises (cantWriteFile); 


}; 

}; 


* The DistributedCaps Server main program. It instantiates a DisCapsImpl 

* object, starts the orb and registers the object with the orb. 

* 

* @author Gary Kreeger 

* @version 1.0 
*/ 
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import DistributedCaps.*; 
import org.omg.CosNaming.*; 
import org.omg.CosNaming.NamingContextPackage.*; 
import org.omg.CORBA.*; 

public class CapsServer 
{ static public void mam(Strmg[] args) 
try 
{ 

// Initialize the ORB 

ORB orb = ORB.mit(args, null); 

// Create the Caps object 
DistCapsImpl caps = new DistCapsImplQ; 
orb.connect (caps); 

//get the root naming context 

org.omg.CORBA.Object obJRef = orb.resolve_initial_references ("NameService"); 
NamingContext ncRef = NamingContextHelper.narrow (obJRef); 

// bind the Object Reference in Naming 

NameComponent nc = new NameComponent ("DistCaps", " "); 

NameComponent path[] = {nc}; 
ncRef.rebind (path, caps); 

//wait for invocations from client 
java.lang.Object sync = new javadang.ObjectO; 
synchronized (sync) 

{ 

sync.waitO; 

} 

} 

catch (Exception e) 

{ 

System.err.println ("Error: " + e); 
e.printStackTrace (System.out); 

} 

}//end CapsServer 
/*♦ 

* The Implementation for the distributed CAPS object. 

* 

* @author Gary Kreeger 

* @version 1.0 
*/ 


import DistributedCaps.*; 
import java.io.*; 
import java.io.File; 
import java.util. Vector; 

import javax.swing.filechooser.FileSystemView; 
public class DistCapsImpl extends DistCapsImplBase 
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{ 

/*♦ 

* the constructor for a distributed CAPS object 
*/ 

DistCapsImplO 

{ 

superO; 

System.out.prmtln ("Caps Object Created"); 

} 


* Translate function for creating Ada files from a PSDL file 

* 

* @param psdl_file The PSDL file to be translated 

* @param name The name of the PSDL file 

* @param version The version number of the PSDL file being translated 

* @param user The name of the user at the client session 

* 

* @retum A string to confirm the file was transfered and translated 

* 

* @throws DistributedCaps.DistCapsPackagexantWriteFile 
*/ 

public String translate (byte[] psdl_file, String name, String version, String user) 
throws DistributedCaps.DistCapsPackage.cantWriteFile 

{ 

boolean tempBool = true; 

String protoHome; 

//MTS 8/25/99 

// added local variable userHome 
String userHome = 

try 

{ 

String CapsServerFiles = System.getProperty("CAPSJavaHome”); 
if (CapsServerFiles — null) // CAPSJavaHome not set on command line 
{ 

//default to the home directory 

File homeDir = FileSystemView.getFileSystemView OgetHomeDirectory (); 
protoHome = new String (homeDir + File.separator + user + 

File.separator + ".caps"); 

//MTS 8/25/99 

// added code to initialize userHome 
userHome = (homeDir + File.separator + user); 

File protoDir = new File (protoHome); 
if (IprotoDir.exists 0 ) 

{ 

protoDir.mkdir 0; 

} 

} 

else 

{ 

protoHome = new String (CapsServerFiles + File.separator + user + 
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File.separator + ".caps"); 

//MTS 8/25/99 

// added code to initialize userHome 

userHome = (CapsServerFiles + File.separator + user); 

File protoDir = new File (protoHome); 
if (IprotoDir.exists 0) 

{ 

protoDir.mkdir 0; 

} 

} 

//ensure the file is created, read the byte array into a FileOutputStream 
//and then read the FileOutputStream into the file 
String proto = name; 

File PSDL_Demo = new File (protoHome + File.separator + name + 
File.separator + version + File.separator + proto + ".psdl"); 
tempBool = PSDL_Demo.createNewFile(); 

FileOutputStream fos = new FileOutputStream (PSDL Demo); 

fos.write (psdl_file); 

fos.closeO; 

} 

catch (Exception e) 

throw new DistributedCaps.DistCapsPackage.cantWriteFileO; 

} 

//MTS 8/25/99 

// replace protoHome with userHome in the following call to translate.script 
// String command = "translate.script" + protoHome + " " + name + " " + version; 

String command = "translate.script" + userHome + " " + name + " " + version; 

try 

{ 

Runtime run = Runtime.getRuntimeQ; 
run.exec(command); 

} 

catch (lOException ex) 

{ 

System.out.println (ex); 

} 

return "\nThe PSDL file was successfully transferred to the serverVn"; 

}//end Translate 

/** 

* Get the list of prototypes available remotely 

* 

* @param user The name of the user at the client session 

* 

* @retum An array of prototype names that may be selected for opening 
*/ 

public String [] get_proto_list(String user) 
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{ 

String [] protolist; 

String CapsServerFiles = System.getProperty(”CAPSJavaHome”); 

String protoHome; 

File protoDir; 

if (CapsServerFiles == null) // CAPSJavaHome not set on command line 

File homeDir = FileSystemView.getFileSystemView 0-gctHomeDirectory (); 
protoHome = new String (homeDir + File, separator + user + 

File.separator + ".caps"); 
protoDir = new File (protoHome); 
if (IprotoDir.exists ()) 

{ 

protoDir.mkdir 0; 

} 

} 

else 

{ 

protoHome = new String (CapsServerFiles + File.separator + user + 
File.separator + ".caps"); 
protoDir = new File (protoHome); 
if (IprotoDir.exists 0) 

{ 

protoDir.mkdir 0; 

} 

} 

// vector to hold prototype names 
Vector prototypeNames = new Vector (0,2); 

// array to hold list of existing files 
File [] dirs = protoDir.listFiles 0; 

if (dirs.length = 0) // no files exist 

{ 

return protolist = new String [0]; 

} 

else 

{ 

for (int ix = 0; ix < dirs.length; ix++) 

{ 

String protoName =""; 
protoName = dirs [ixJ.getName (); 

File subDirs [] = dirs [ix].IistFiles 0; 
for (int jx = 0; jx < subDirs.length; jx-H-) 

{ 

proto1ypeNames.addElement (protoName.concat 
(File.separator + subDirs [jxJ.getName 0)); 

} 

} 

//get the vector into an object array and then convert it to a string array 
Object [] tempjproto_list = prototypeNames.toArray 0; 
protolist = new String [temp_proto_list.length]; 

for (int ix = 0; ix < tempjproto_list.length; ix++) 
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{ 

protolist[ix] = String.valueOf (temp__proto_list[ix]); 

} 

return protolist; 

} 

}//end get_j)rotoJist 


* Open the selected prototype 

* 

* @param name The name of the prototype opened 

* @param user The name of the user at the client session 

* 

* @retum A byte array holding the selected prototype PSDL file 

♦ 

* ©throws DistributedCaps.DistCapsPackagexantReadFile 
*/ 

public byte[] openjroto (String name, String user) 
throws DistributedCaps.DistCapsPackagexantReadFile 

{ 

try 

{ 

byte[] proto_file; 

String CapsServerFiles “ System.getProperty("CAPSJavaHome"); 

String protoHome; 

File protoDir; 

if (CapsServerFiles = null) // CAPSJavaHome not set on command line 

{ 

File homeDir = FileSystemView.getFileSystemView ().getHomeDirectory (); 
protoHome = new String (homeDir + File.separator + user + 

File.separator + ".caps"); 
protoDir = new File (protoHome); 
if (IprotoDir.exists Q) 

{ 

protoDir.mkdir 0; 

} 

} 

else 

{ 

protoHome = new String (CapsServerFiles + File.separator + user + 
File.separator + ".caps"); 
protoDir = new File (protoHome); 
if (IprotoDir.exists 0) 

{ 

protoDir.mkdir (); 

} 

} 

if (name == null) 

{ 

return proto_file = new byte[0]; 

} 
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else 

{ 

// create file object with which to manipulate the selected file 
File selectedDir = new File (protoHome + File.separator + name); 
File file = new File (selectedDir.getAbsolutePath () + File.separator + 
selectedDir.getParentFile Q-getName 0 + ".psdl"); 
if (Ifile.exists 0) 

{ 

return proto_file = new byte[0]; 

} 

else 

{ 

//read the opened file into a FileInputStream and then read the 
//FileInputStream in the byte array to be returned 
FileInputStream in = new FileInputStream (file); 
proto_file = new byte[in.available0]; 
in.read (proto_file); 
return proto_fiIe; 


} 


} 


} 

catch (Exception e) 
{ 


throw new DistributedCaps.DistCapsPackage.cantReadFileO; 

} 


}//end open_proto 


* Save a prototype's PSDL file on a local client to the remote server 

* 

* @param psdl_file The PSDL file to be translated 

* @param name The name of the PSDL file 

* @param version The version number of the PSDL file being translated 

* @param user The name of the user at the client session 

* 

* @retum A string to confirm the file was transfered 

* 

* @throws DistributedCaps.DistCapsPackage.cantWriteFile 
*/ 

public String commit (byte[] psdl_file. String name, String version. String user) 
throws DistributedCaps.DistCapsPackage.cantWriteFile 

{ 

boolean tempBool = true; 

String protoHome = 

String proto = name; 

String completePath = 

try 

{ 

String CapsServerFiles = System.getProperty("CAPSJavaHome"); 
if (CapsServerFiles = null) // CAPSJavaHome not set on command line 
{ 
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File homeDir = FileSystemView.getFileSystemView ().getHomeDirectory (); 

protoHome = (homeDir + File.separator + user + 

File.separator + ".caps"); 

File protoDir = new File (protoHome); 
if (IprotoDir.exists 0) 

{ 

protoDir.mkdir (); 

} 

} 

else 

{ 

protoHome = (CapsServerFiles + File.separator + user + 

File.separator + ".caps"); 

File protoDir = new File (protoHome); 
if (IprotoDir.exists ()) 

{ 

tempBool = protoDir.mkdirs 0; 

} 

} 

completePath = (protoHome + File.separator + name + File.separator + version); 
File completeDirs “ new File (completePath); 

if (IcompleteDirs.exists 0) // ensure the correct directory exist to save to 
{ 

tempBool = completeDirs.mkdirsO; 

} 

//ensure the file is created, read the byte array into a FileOutputStream 
//and then read the FileOutputStream into the file 

File PSDL_Demo = new File (completePath + File.separator + proto + ".psdl"); 
tempBool = PSDL_Demo.createNewFile(); 

FileOutputStream fos = new FileOutputStream (PSDL^Demo); 

fos.write (psdl__file); 

fos.closeO; 

} 

catch (Exception e) 

{ 

System.out.prmtln (e); 

throw new DistributedCaps.DistCapsPackage.cantWriteFileO; 

} 

return "\nThe PSDL file was successfully transferred to the serverVn"; 

} 

}//end commit 
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Class 


Tree Deprecated Index Help 

PREV CLASS NEXT CLASS FRAMES NO FRAMES 

SUMMARY: INNER | FIELD | CONSTR 1 METHOD DETAIL; FIELD | CONSTR | METHOD 


Class CapsServer 

j ava.lang.Obj ect 
I 

+—CapsServer 


public class CapsServer 
extends java.lang.Object 


The DistributedCaps Server main program. It instantiates a DisCapsImpl object, starts the orb and registers 
the object with the orb. 


Constructor Summary 

CapsServer() 


Method Summary 

static void 

main(java.lang,String[] args) 


Methods inherited from class java.lang.Object 

clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, 
wait, wait 


Constructor Detail 


CapsServer 

public CapsServer() 


Method Detail 


main 

public static void main(java.lang.String[] args) 
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Class 


I Tree Deprecated Index Help 

PREV CLASS NEXT CLASS 
SUMMARY: INNER | FIELD | CONSTR | METHOD 


FRAMES NO FRAMES 

DETAIL: FIELD | CONSTR I METHOD 


Class DistCapsImpl 

j ava.lang.Obj ect 

I 

+—org.orag.CORBA.portable.Obj ectlmpl 

I 

+—org.omg.CORBA.Dynamiclmplementation 

I 

+—DistributedCaps._DistCapsImplBase 

I 

+—DistCapsImpl 


public class DistCapsImpl 

extends DistributedCaps._DistCapsImplBase 

The Implementation for the distributed CAPS object. 

See Also: 

Serialized Form 


Method Summary 

java.lang.String 

conuait (byte [] psdi file^ java. lang. String name, 
java.lang.string version, java.lang.String user) 

Save a prototype's PSDL file on a local client to the remote server 

j ava.lang.String[] 

get proto list(java.lang.String user) 

Get the list of prototypes available remotely 

byte [] 

Open proto (java.lang.String name, java.lang.String user) 

Open the selected prototype 

j ava.lang.String 

translate(byte[] psdl_file, java.lang.String name, 
java.lang.String version, java.lang.String user) 

Translate function for creating ADA files from a PSDL file 


Methods inherited f rom class DistributedCaps._DistCapsImplBase 

ids, invoke _ 
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Methods inherited from class org.omg.CORBA.portabIe.Objectlmpl 

_create_request, _create_request, ^duplicate, _get_delegate, _get_domain_managers, 
_get_interface_def, _get_policy, _hash, __invoke, _is_equivalent, _is_local, 

_non_existent, _orb, ^release, _releaseReply, ^request, ^request, 

_servant_postinvoke, __servant_preinvoke, _set_deiegate, _set_policy__override, 
equals, hashCode, toString 


Methods inherited from class java.lang.Object 

clone, finalize, getClass, notify, notifyAll, wait, wait, wait 


Method Detail 


translate 

public java^lang.String translate(byte[] psdl_file, 

java.lang.String name, 
java.lang.String version, 
java.lang.String user) 

throws DistributedCaps.DistCapsPackage.cantWriteFile 

Translate function for creating ADA files from a PSDL file 
Overrides: 

translate in class DistributedCaps._DistCapsImplBase 
Parameters: 

psdi_f iie - The PSDL file to be translated 
name - The name of the PSDL file 

version - The version number of the PSDL file being translated 
user - The name of the user at the client session 

Returns: 

A string to confirm the file was transfered and translated 
Throws: 

DistributedCaps.DistCapsPackage.cantWriteFile - 


get_proto_list 

public java.lang.String[] get_proto_list(java.lang.String user) 

Get the list of prototypes available remotely 
Overrides: 

. get_proto_list in class DistributedCaps._DistCapsImpiBase 

Parameters: 

user - The name of the user at the client session 

Returns: 

An array of prototype names that may be selected for opening 
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open_proto 

public byte[] open__proto (java. lang. String name, 

java.lang.String user) 

throws DistributedCaps.DistCapsPackage.cantReadFile 

Open the selected prototype 
Overrides: 

open_proto in class DistributedCaps._DistCapsIniplBase 
Parameters: 

name - The name of the prototype opened 
user - The name of the user at the client session 

Returns: 

A byte array holding the selected prototype PSDL file 

Throws: 

DistributedCaps.DistCapsPackage.cantReadFile - 


commit 


public java.lang.String commit (byte[] psdl_file, 

java.lang.String name, 
java.lang.String version, 
java.lang.String user) 

throws DistributedCaps.DistCapsPackage.cantWriteFile 

Save a prototype's PSDL file on a local client to the remote server 
Overrides: 

commit in class DistributedCaps._DistCapsImplBase 
Parameters: 

psdl_file - The PSDL file to be translated 
name - The name of the PSDL file 

version - The version number of the PSDL file being translated 
user - The name of the user at the client session 

Returns: 

A string to confirm the file was transfered 
Throws: 

DistributedCaps.DistCapsPackage.cantWriteFile - 


Tree Deprecated Index Hein 

PREV CLASS NEXT CLASS FRAMES NO FRAMES 

SUMMARY: INNER | FIELD | CONSTR I METHOD DETAIL: FIELD I CONSTR I METHOD 


Class 
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APPENDIX C: IDL-TO-JAVA COMPILER GENERATED SOURCE CODE 


This appendix contains the source files and corresponding Javadoc generated 
documentation for the files created by the IDL-to-Java compiler when creating the 
distributed CAPS server. 

/♦ 

* File: ./DISTRIBUTEDCAPS/DISTCAPS.JAVA 

♦ From: DISTCAPS.IDL 

♦ Date: Wed Aug 18 20:38:43 1999 

* By: idltojava Java IDL 1.2 Aug 18 1998 16:25:34 
♦/ 

package DistributedCaps; 
public interface DistCaps 

extends org.omg.CORBA.Object, org.omg.CORBA.portable.IDLEntity { 

String translate(byte[] psdl_file, String name, String version. String user) 
throws DistributedCaps.DistCapsPackage.cantWriteFile; 

String[] get_proto_list(String user); 
byte[] open_proto(String name. String user) 
throws DistributedCaps.DistCapsPackage.cantReadFile; 

String commit(byte[] psdl_file. String name, String version. String user) 
throws DistributedCaps.DistCapsPackage.cantWriteFile; 

} 


/* 

* File: ./DISTRIBUTEDCAPS/_DISTCAPS1MPLBASE.JAVA 

* From: DISTCAPS.IDL 

* Date: Wed Aug 18 20:38:43 1999 

* By: idltojava Java IDL 1.2 Aug 18 1998 16:25:34 

package DistributedCaps; 

public abstract class DistCapsImplBase extends org.omg.CORBA.DynamicImplementation implements 
DistributedCaps.DistCaps { 

// Constructor 

public _DistCapsImpIBaseO { 
superO; 

} 

// Type strings for this class and its superclases 
private static final String _type_ids[] = { 

"IDL:DistributedCaps/DistCaps: 1.0" 

}; 


public StringQ JdsQ { return (String[]) _type_ids.clone(); } 

private static java.util.Dictionaiy_methods = new java.util.HashtableO; 
static { 
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_methods.put("translate", new java.lang.lnteger(0)); 

_methods.put("get_proto_list", new java.lang.Integer( 1)); 

_niethods.put("open_proto", new java.lang.Integer(2)); 

_methods.put("commit", new java.lang.Integer(3)); 

} 

// DSI Dispatch call 

public void invoke(org.omg.CORBA.ServerRequest r) { 
switch (((java.lang.Integer) _methods.get(r.op_name())).intValueO) { 
case 0: // DistributedCaps.DistCaps.translate 
{ 

org.omg.CORBA.NVList list = _orb0.create_list(0); 
org.omg.COREA.Any j>sdl file = orb0 create_any0; 
_j)sdl_file.type(DistributedCaps,DistCapsPackage.prototype_fileHelper.type()); 
_list.add_value("psdl_file”, _j)sdl_file, org.omg.CORBA.ARG_IN. value); 
org.omg.COREA.Any _name = _orb0.create_any(); 

_name.type(org.omg.CORBA.ORB.init0.getjprimitive_tc(org.omg.CORBA.TCKmd.tk_string)); 
Jist.add_value(”name”, _name, org.omg.CORBA.ARG_IN.value); 
org.omg.COREA.Any ^version = _orb().create_anyO; 
_version.type(org.omg.COREA.ORE.init0.getj>rimitive_tc 
(org.omg.COREA.TCKind.tk^string)); 

_list.add_value("version”, ^version, org.omg.COREA.ARG_IN.value); 
org.omg.COREA.Any _user = _orb0create_any0; 

_user.type(org.omg.COREA.ORE.init0.getj)rimitive_tc(org.omg.CORBA.TCKind.tk_string)); 
_list.add__value("iiser", _user, org.omg.COREA.ARG__IN.value); 
r.params(_list); 
byte[] psdl__file; 

psdl_file = DistributedCaps.DistCapsPackage.prototype_fileHelper.extract(jpsdl_file); 

String name; 

name = _name.extract_string(); 

String version; 

version = __version.extract_stringO; 

String user; 

user = _user.extract_stringO; 

String_^result; 

try { 

_^result = this.translate(psdl_file, name, version, user); 

} 

catch (DistributedCaps.DistCapsPackage.cantWriteFile eO) { 
org.omg.COREA.Any __except = _orb0.create_any0; 
DistributedCaps.DistCapsPackage.cantWriteFileHelper.insert(_except, eO); 
r.except(_except); 
return; 

} 

org.omg.COREA.Any_^result = _orb0.create_any0; 

_^result.insert_string(_^result); 

r.result(_^result); 

} 

break; 

case l://DistributedCaps.DistCaps.get_proto_list 

{ 

org.omg.CORBA.NVList _list = _orb0.create_list(0); 
org.omg.CORBA.Any user = _orb0.create_any(); 

_user.type(org.omg.CORBA.ORB.init0.get_primitive_tc(org.omg.CORBA.TCKind.tk_string)); 

_list.add_value("user", user, org.omg.CORBA.ARG_IN.value); 

r.params(_list); 

String user; 
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user = _user.extract_strmgO; 

Strmg[]_^result; 

_result = this.get_proto_list(user); 

org.omg.CORBA.Any_^result = _orb0.create_any0; 

DistributedCaps.DistCapsPackage.prototype_listHelper.insert(_result,_^result); 

r.result(_^result); 

} 

break; 

case 2: // DistributedCaps.DistCaps.open_proto 

{ 

org.omg.CORBA.NVList _list = _orb0.create_list(0); 
org.omg.CORBA.Any _name = _orb().create_any(); 

_name.type(org.omg.CORBA.ORB.init0.get_primitive_tc(org.omg.CORBA.TCKind.tk_string)); 
_list.add_value("name", _name, org.omg.CORBA.ARG_IN.value); 
org.omg.CORBA.Any _user = _orb0.create_any0; 

_user.type(org.omg.CORBA.ORB.mit0.get_primitive_tc(org.omg.CORBA.TCKind.tk_string)); 

_list.add_value("user", _user, org.omg.CORBA.ARG_IN. value); 

r.params(_list); 

String name; 

name = _name.extract_stringO; 

String user; 

user = _user.extract_strmgO; 

byte[]_result; 

try { 

_^result = this.openj5roto(naine, user); 

} 

catch (DistributedCaps.DistCapsPackage.cantReadFile eO) { 
org.omg.CORBA.Any ^except = _orb().create_any(); 
DistributedCaps.DistCapsPackage.cantReadFileHelper.insert(_except, eO); 
r.except(_except); 
return; 

} 

org.omg.CORBA.Any_^result = _orb().create__any(); 

DistributedCaps.DistCapsPackage.prototype_fileHelper.insert(_^result,_^result); 

r.result(_^result); 

} 

break; 

case 3: // DistributedCaps.DistCaps.commit 

{ 

org.omg.CORBA.NVList _list = orb().create_list(0); 
org.omg.CORBA.Any _psdl file == _orb0.create_any0; 
_psdl__file.type(DistributedCaps.DistCapsPackage.prototype_fileHelper.type()); 
_list.add_value('‘psdl_file”, _psdl_fiie, org.omg.CORBA.ARG_IN. value); 
org.omg.CORBA.Any _name - _orb0.create_any0; 

_name.type(org.omg.CORBA.ORB.init0.getj)rimitive__tc(org.omg.CORBA.TCKind.tk_string)); 
_list.add_value(”name”, _name, org.omg.CORBA.ARG IN.value); 
org.omg.CORBA.Any _version = _orbOxreate_any(); 
_version.type(org.omg.CORBA.ORB.init0.get_primitive tc 
(org.omg.CORBA.TCKind.tkstrmg)); 

_list.add value(’'version”, version, org.omg.CORBA.ARG_IN.value); 
org.omg.CORBA.Any _user = _orb0.create_any(); 

_user.type(org.omg.CORBA.ORB.init0.get^rimitive_tc(org.omg.CORBA.TCKind.tk_string)); 
_list.add_value("user", _user, org.omg.CORBA.ARG_IN.value); 
r.params(__list); 
byte[] psdl_file; 

psdl_file = DistributedCaps.DistCapsPackage.prototype_fileHelper.extract(jpsdl_file); 


107 


String name; 

name = _name.extract__strmgO; 

String version; 

version = _version.extract_stringO; 

String user; 

user = _user.extract_string(); 

String_^result; 

tiy { 

_result = thisxommit(psdl__file, name, version, user); 

} 

catch (DistributedCaps.DistCapsPackagexantWriteFile eO) { 
org.omg.CORBA.Any except = _orb0.create_any0; 
DistributedCaps.DistCapsPackagexantWriteFileHelper.insert(_except, eO); 
rxxcept(_except); 
return; 

} 

org.omg.CORBA.Any_result = _orb0.create_any0; 

_^result.insert_string(_^result); 

r.result(_^result); 

} 

break; 

default: 

throw new org.omg.CORBA.BAD_OPERATION(0, 
org.omg.CORBA.CompletionStatus.COMPLETEDMAYBE); 

} 

} 

} 


/♦ 

♦ File: ./DISTRIBUTEDCAPS/_DISTCAPSSTUB.JAVA 

♦ From: DISTCAPS.IDL 

♦ Date: Wed Aug 18 20:38:43 1999 

♦ By: idltojava Java IDL 1.2 Aug 18 1998 16:25:34 
*1 

package DistributedCaps; 
public class _DistCapsStub 

extends org.omg.CORBA.portable.ObjectImpl 
implements DistributedCaps.DistCaps { 

public _DistCapsStub(org.omg.CORBA.portable.Delegate d) { 
superO; 

_set_delegate(d); 

} 

private static final String _type_ids[] = { 
"IDL:DistributedCaps/DistCaps: 1.0" 

}; 


public String[] _idsO {return (String!]) _typejds.clone0;} 

// IDL operations 

// Implementation of: :DistributedCaps: :DistCaps: :translate 

public String translate(byte[] psdl_file, String name. String version, String user) 
throws DistributedCaps.DistCapsPackage.cantWriteFile { 
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org.omg.CORBA.Request r = _request("translate"); 

r.set_retum_type(org.omg.CORBA.ORB.mitOget_primitive_tc(org.omg.CORBA.TCKmd.tk_string)); 
org.omg.CORBA.Any _psdl_file = r.add_m_arg(); 

DistributedCaps.DistCapsPackage.prototype_fileHeIper.insert(_psdl_file, psdlfile); 
org.omg.CORBA.Any _name = r.add_m_argO; 

_name.insert_strmg(name); 
org.omg.CORBA.Any version = r.add_m_argO; 

_version.msert_string(version); 
org.omg.CORBA.Any _user = r.add_in_argO; 

_user.insert_strmg(user); 

r.exceptions0.add(DistributedCaps.DistCapsPackage.cantWriteFiIeHelper.type()); 

r.invokeO; 

java.lang.Exception_ex = r.envO.exceptionO; 

if (_ex instanceof org.omg.CORBA.Unkno\vnUserException) { 

org.omg.CORBA.UnknownUserException_^userEx = (org.omg.CORBA.UnknownUserException) 

ifC_userEx.except.type0.equals(DistributedCaps.DistCapsPackage.cantWriteFileHelper.type())) { 
throw DistributedCaps.DistCapsPackage.cantWriteFileHelper.extract(_userEx.except); 

} 

} 

String_^result; 

_^result = r.retum_value0.extract_stringO; 

return_^result; 

} 

// Implementation of ::DistributedCaps::DistCaps::get_j)roto list 
public String[] get_proto__list(String user) 

org.omg.CORBA.Request r = _request(”get_proto_list"); 
r.set_retum_type(DistributedCaps.DistCapsPackage.prototype_listHelper.type()); 
org.omg.CORBA.Any __user = r.add_in_arg(); 

__user.insert_string(user); 

r.invokeO; 

String[]_^result; 

_result = DistributedCaps.DistCapsPackage,prototype_listHelper.extract(r.retum_valueO); 

return_^result; 

} 

// Implementation of ::DistributedCaps::DistCaps::open_proto 
public byte[] open_proto(String name, String user) 
throws DistributedCaps.DistCapsPackage.cantReadFile { 
org.omg.CORBA.Request r = _request(”open_proto"); 
r.set_retum_type(DistributedCaps.DistCapsPackage.prototype_fileHeiper.typeO); 
org.omg.CORBA.Any _name = r.add_in_argO; 

_name.insert_string(name); 
org.omg.CORBA.Any _user = r.addin_argO; 

_user.insert_string(user); 

r.exceptions0.add(DistributedCaps.DistCapsPackage.cantReadFileHelper.typeO); 

r.invokeO; 

java.lang.Exception_ex = r.envO.exceptionO; 

if (_ex instanceof org.omg.CORBA.UnknownUserException) { 

org.omg.CORBA.UnknownUserException_^userEx = (org.omg.CORBA.UnknownUserException) 

if (_^userEx.except.type0.equals(DistributedCaps.PistCapsPackage.cantReadFileHelper.typeO)) { 

throw DistributedCaps.DistCapsPackage.cantReadFileHelper.extract(_userEx.except); 

} 

} 

byte[]_^result; 

_^result = DistributedCaps.DistCapsPackage.prototype_fileHelper.extract(r.retum_valueO); 

return_^result; 



} 

// Implementation of ::DistributedCaps::DistCaps::commit 
public String commit(byte[] psdl_file. String name, String version, String user) 
throws DistributedCaps.DistCapsPackage.cantWriteFile { 
org.omg.CORBA.Request r == _request("commit"); 

r.set_retum_type(org.omg.CORBA.OI^.init0.get_primitive__tc(org.omg.CORBA.TCKind.tk_string)); 
org.omg.CORBA.Any _psdl file = r.add in argO; 

DistributedCaps.DistCapsPackage.prototype_fileHeIper.insert(j)sdl_file, psdl_file); 
org.omg.CORBA.Any _name = r.addinargO; 

_name.insert_string(name); 
org.omg.CORBA.Any ^version = r.add_in_argO; 

_version.msert_string(version); 
org.omg.CORBA.Any _user == r.add_in_argO; 

_user.insert_string(user); 

r.exceptionsO.add(DistributedCaps.DistCapsPackage.cantWriteFileHelper.typeO); 

r.invokeO; 

java.lang.Exception_^ex = r.envO.exceptionQ; 

if (_ex instanceof org.omg.CORBA.UnknownUserException) { 

org.omg.CORBA.UnknownUserException_^userEx = (org.omg.CORBA.UnknownUserException)_ex 

if(_^userEx.except.type().equals(DistributedCaps.DistCapsPackage.cantWriteFileHelper.type())) { 

throw DistributedCaps.DistCapsPackage,cantWriteFileHelper,extract(_^userEx.except); 

} 

} 

String_^result; 

_^result = r.retum__value0.extract_stringO; 

return_^result; 


}; 


/* 

* File: ./DISTRIBUTEDCAPS/DISTCAPSHELPERJAVA 

* From: DISTCAPS.IDL 

* Date: Wed Aug 18 20:38:43 1999 

* By: idltojava Java IDL 1.2 Aug 18 1998 16:25:34 
*! 

package DistributedCaps; 
public class DistCapsHelper { 

// It is useless to have instances of this class 
private DistCapsHelperQ {} 

public static void write(org.omg.CORBA.portable.OutputStream out, DistributedCaps.DistCaps that) { 
out.\vrite_Object(that); 

} 

public static DistributedCaps.DistCaps read(org.omg.CORBA.portable.InputStream in) { 
return DistributedCaps.DistCapsHelper.narrow(in.read_Object0); 

} 

public static DistributedCaps.DistCaps extract(org.omg.CORBA.Any a) { 
org.omg.CORBA.portable.InputStream in = a.create_input_streamO; 
return read(in); 

} 

public static void insert(org.omg.CORBA.Any a, DistributedCaps.DistCaps that) { 
org.omg.CORBA.portable.OutputStream out = a.createoutput_stream(); 
write(out, that); 


no 



a.read_value(out.create_input_stream(), typeQ); 

} 

private static org.omg.CORBA.TypeCode _tc; 
synchronized public static org.omg.CORBA.TypeCode type() { 
if (_tc = null) 

_tc = org.omg.CORBA.ORB.init0.create_interface_tc(id(), "DistCaps"); 
return _tc; 

} 

public static String idQ { 
return "IDL;DistributedCaps/DistCaps: 1.0"; 

} 

public static DistributedCaps.DistCaps narrow(org.omg.CORBA.Objectthat) 
throws org.omg.CORBA.BAD_PARAM { 
if (that = null) 
return null; 

if (that instanceof DistributedCaps-DistCaps) 
return (DistributedCaps.DistCaps) that; 
if (!that.Js_a(id())) { 

throw new org.omg.CORBA.BAD_PARAM(); 

} 

org.omg.CORBA.portable.Delegate dup = ((org.omg.CORBA.portable.ObjectImpl)that)._get_delegateO; 
DistributedCaps.DistCaps result = new DistributedCaps._DistCapsStub(dup); 
return result; 

} 

} 


/* 

* File: ./DISTRIBUTEDCAPS/DISTCAPSHOLDER.JAVA 

* From: DISTCAPS.IDL 

* Date: Wed Aug 18 20:38:43 1999 

* By: idltojava Java IDL 1.2 Aug 18 1998 16:25:34 
*/ 

package DistributedCaps; 
public final class DistCapsHolder 

implements org.omg.CORB A.portable.Streamable { 

// instance variable 

public DistributedCaps.DistCaps value; 

// constructors 

public DistCapsHolder() { 
this(null); 

} 

public DistCapsHolder(DistributedCaps.DistCaps arg) { 
value = arg; 

} 

public void _write(org.omg.CORBA.portable.OutputStream out) { 
DistributedCaps.DistCapsHelper.write(out, value); 

} 

public void _read(org.omg.CORBA.portable.InputStream in) { 
value = DistributedCaps.DistCapsHelper.read(in); 

} 

public org.omg.CORBA.TypeCode _typeO { 
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return DistributedCaps.DistCapsHelper.typeQ; 

} 

} 
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Class 


Tree Deprecated Index Help 


PREV CLASS NEXT CLASS FRAMES NO FRAMES 

SUMMARY: INNER | FIELD | CONSTR | METHOD DETAIL: FIELD | CONSTR | METHOD 


DistributedCaps 

Interface DistCaps 

All Known Implementing Classes: 

DistCapsIniplBase. DistCapsStub 


public interface DistCaps 

extends org.omg.CORBA.Object, org.omg.CORBA.portable.IDLEntity 


I 

Method Summary | 

j ava,lang.String 

commit(byte[] psdl file, java.lang.String name, 
java.lang.String version, java.lang.String user) 

j ava.lang.String[] 

get proto list(java.lang.String user) 

byte[] 

open proto(java.lang.String name, java.lang.String user) 

java.lang.String 

translate(byte[] psdl file, java.lang.String name, 

java.lang.String version, java.lang.String user) j 

__._.i 


Methods inherited from interface org.omg.CORBA.Object 

_create__request, __create__request, ^duplicate, _get_domain_managers, 
_get_interface_def, _get_policy, _hash, _is_a, _is_equivalent, _non_existent, 
^release, ^request, _set_policy_override 


Method Detail 


translate 

public j ava. lang. String translate (byte [ ] psdl__fiie, 

java.lang.String name, 
java.lang.String version, 
java.lang.String user) 

throws DistributedCaps.DistCapsPackage.cantWriteFile 
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get_proto_list 

public java.lang.String[] get_proto_list(java.lang.String user) 


open_proto 

public byte[] open^proto(java.lang.String name, 

java.lang.String user) 

throws DistributedCaps.DistCapsPackage.cantReadFile 


commit 

public java.lang.String commit (byte[] psdl_file, 

java.lang.String name, 
java.lang.String version, 
java.lang.String user) 

throws DistributedCaps.DistCapsPackage.cantWriteFile 


Class 


Tree Denrecated Index Help 


PREV CLASS NEXT CLASS 
SUMMARY: INNER 1 FIELD | CONSTR | METHOD 


FRAMES NO FRAMES 

DETAIL: FIELD I CONSTR I METHOD 
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Class 


Tree Deprecated Index Help 

PREV CLASS NEXT CLASS FRAMES NO FRAMES 

SUMMARY: INNER | FIELD | CONSTR | METHOD DETAIL; FIELD | CONSTR | METHOD 


DistributedCaps 

Class _DistCapsImplBase 

java.lang.Object 

I 

+—org.omg.CORBA.portable.Obj ectImpl 

I 

+—org.omg.CORBA.Dynamicimplementation 

I 

+—DistributedCaps .^DistCapsImplBase 


public abstract class _DistCapsImplBase 
extends org.omg.CORBA.DynamicImplementation 
implements DistCaps 

See Also: 

Serialized Form 


Constructor Summary 

DistCapsImplBase () 


. . M.. , , 1 

Method Summary 

j ava.lang.String[] 

ids () 

t 

[ 

void 

invoke(org.omg.CORBA.ServerRequest r) 

i 


Methods inherited from class org.omg.CORBA.portabIe.ObjectImpl 

_create_request, _create_request, ^duplicate, _get_delegate, _get_domain_managers, 
_get_interface_def, _get_policy, _hash, ^invoke, _is_a, _is_equivalent, _is_local, 
_non__existent, _orb, __release, _releaseReply, ^request, ^request, 

__servant_postinvoke, _servant_preinvoke, _set_delegate, _set_policy_override, 
equals, hashCode, toString 


Methods inherited from class java.lang.Object 

clone, finalize, getClass, notify, notifyAll, wait, wait, wait 
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Constructor Detail 


_DistCapsImplBase 

public _DistCapsImplBase() 

Method Detail _ 

_ids 

public java.lang.String [] _idi() 

Overrides: 

_ids in class org.omg.CORBA.portable.Objectlmpl 

invoke 

public void invoke (org.omg.CORBA.ServerReguest r) 

Overrides: 

invoke in class org.omg.CORBA.DynamicImplementation 
|3E^^ Tree Deprecated Index Help 

PREV CLASS NEXT CLASS 
SUMMARY: INNER 1 FIELD | CONSTR \ METHOD 


FRAMES NO FRAMES 

DETAIL: FIELD I CONSTR I METHOD 
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Class 


Tree Deprecated Index Help 

PREV CLASS NEXT CLASS FRAMES NO FRAMES 

SUMMARY; INNER | FIELD | CONSTR | METHOD DETAIL; FIELD | CONSTR | METHOD 


DistributedCaps 

Class _DistCapsStub 

j ava.lang.Obj ect 

1 

+—org. omg. CORBA. port able. Ob j ect Irtipl 

I 

+—DistributedCaps ,_DistCapsStiab 


public class _DistCapsStub 

extends org.omg.CORBA.portable.Objectlmpl 

implements DistCaps 

See Also: 

Serialized Form 


Constructor Summary 

DistCapsStub (org.omg.CORBA.portable.Delegate d) 


Method Summary 

j ava.lang.String[] 

ids 0 

java.lang,String 

commit(byte[] psdl file, iava,lana.Strina name, 
java.lang.String version, java.lang.String user) 

j ava.lang.String[] 

get proto list(java.lang,Strinq user) 

byte[] 

open proto(java.lanq.String name, java.lang.Strina user) 

java.lang.String 

translate(byte [] psdl file, i ava.lang.String name, 
java.lang.String version, java.lang.String user) 
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Methods inherited from class org.omg.CORBA.portable.OhjectImpI 

_create_request, _create_request, ^duplicate, _get_delegate, 

_get_domain_managers, _get_interface__def, _get_policy, _hash, ^invoke, __is_a, 
_is__equivalent, _is_locai, _non_existent, _orb, __release^ _releaseReply, 
^request, __request, __servant_postinvoke, _servant_preinvoke, _set_delegate, 
_set_policy_override, equals, hashCode, toString 


Methods inherited from class java.Iang.Object 

clone, finalize, getClass, notify, notifyAll, wait, wait, wait 


Constructor Detail 


_DistCapsStub 

public _^DistCapsStub(org.omg.C0R3A.portable.Delegate d) 


Method Detail 


_ids 

public java.lang.String[] _ids() 

Overrides: 

_ids in class org.omg.CORBA.portable.Objectlmpl 


translate 

public java.lang. String translate (byte [ ] pscil_file, 

java.lang.String name, 
java.lang.String version, 
java.lang.String user) 

throws DistributedCaps.DistCapsPackage.cantWriteFile 


Specified by: 

tr anslate in interface DistCaps 


get_proto_list 

public java.lang.String[] get_proto_list(java.lang.String user) 

Specified by: 

getjproto list in interface Pi: . Cap s 
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openjproto 


public byte[] open_proto (java.lang.String name, 

java.lang.String user) 

throws DistributedCaps.DistCapsPackage.cantReadFile 


Specified by: 

open proto in interface DistCaps 


commit 

public java. lang. String commit (byte [ ] psdl__file, 

java.lang.String name, 
java.lang.String version, 
java.lang.String user) 

throws DistributedCaps.DistCapsPackage.cantWriteFile 


Specified by: 

commit in interface DistCaps 


Class 


Tree Deprecated Index Help 


PREV CLASS NEXT CLASS 
SUMMARY: INNER | FIELD | CONSTR | METHOD 


FRAMES NO FRAMES 

DETAIL: FIELD | CONSTR | METHOD 
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Class 


Tree Deprecated Index Help 


PREV CLASS NEXT CLASS FRAMES NO FRAMES 

SUMMARY: INNER | FIELD | CONSTR | METHOD DETAIL: FIELD | CONSTR | METHOD 


DistributedCaps 

Class DistCapsHelper 

j ava.lang.Obj ect 

I 

+--DistributedCaps.DistCapsHelper 


public class DistCapsHelper 
extends java.lang.Obj ect 


Method Summary 

static DistCacs 

extract(org.omg.CORBA.Any a) 

static java.lang.String 

id{) 

static void 

insert(org.omg.CORBA.Any a, DistCaps that) 

static DistCavs 

narrow(org.omg.CORBA.Obj ect that) 

static DistCaps 

read(org.omg.CORBA.portable.InputStream in) 

static org.omg.CORBA.TypeCode 

type () 

static void 

write(org.omg.CORBA.portable.OutputStream out, 

DistCaos that) 

.j 


Methods inherited from class java.lang.Object 

clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, 
wait, wait 


Method Detail 


write 
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public static void write(org.omg.CORBA.portable.OutputStream out, 

DistCaps that) 


read 


public static DisrCaos read(org.omg.CORBA.portable.InputStream in) 


extract 


public static DistCaos extract{org.omg.CORBA.Any a) 


insert 


public static void insert(org.omg.CORBA.Any a, 

DistCaps that) 


type 

public static org.omg.CORBA.TypeCode type() 


id 


public static java.lang.String id{) 


narrow 

public static DistCaps narrow(org.omg.CORBA.Object that) 

throws org.omg.CORBA.BAD_PARAM 


Class 


Tree Deprecated Index Help 


PREV CLASS NEXT CLASS 
SUMMARY: INNER | FIELD | CONSTR 1 METHOD 


FRAMES NO FRAMES 

DETAIL: FIELD | CONSTR | METHOD 
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Class 


Tree Deprecated Index Help 


PREV CLASS NEXT CLASS FRAMES NO FRAMES 

SUMMARY; INNER | FIELD | CONSTR | METHOD DETAIL: FIELD ] CONSTR | METHOD 


DistributedCaps 

Class DistCapsHolder 

j ava.lang.Obj ect 

I 

+--DistributedCaps.DistCapsHolder 


public final class DistCapsHolder 
extends java.lang.Object 

implements org.omg.CORBA.portable.Streamable 


Field Summary 


DistCaps 


value 


Constructor Summary 

DistCapsHolder() 


DistCapsHolder(DistCaps _arg) 


Method Summary 

void 

read(org.omg.CORBA.portable.Inputstream in) 

org.omg.CORBA.TypeCode 

typeO 

void ^ 

write(org.omg.CORBA.portable.OutputStream out) 


Methods inhe rited from class java.lang.Object __ 

clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, 
wait, wait 
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Field DetaU ' 

■- - --- - __■ • ' _ I 


value 

public PistCaps value 

Constructor Detail 

DistCapsHolder 

public DistCapsHolder() 


DistCapsHolder 

public DistCapsHolder( DiscCacs _arg) 

Method Detail 

_write 

public void _write(org.omg.CORBA.portable.OutputStream out) 

Specified by: 

_write in interface org.omg.CORBA.portable.Streamable 


_read 

public void _read(org.omg.CORBA.portable.InputStream in) 

Specified by: 

_read in interface org.omg.CORBA.portable.Streamable 


-type 

public org.omg.CORBA.TypeCode _type() 

Specified by: 

_type in interface org.omg.CORBA.portable.Streamable 


Class 


Tree Deprecated Index Help 


PREV CLASS NEXT CLASS 
SUMMARY: INNER I FIELD I CONSTR I METHOD 


FRAMES NO FRAMES 

DETAIL: FIELD I CONSTR I METHOD 
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APPENDIX D: MODIFIED HSI SOURCE CODE 


This appendix contains the HSI source files that were modified from [DURA99] 
and the corresponding Javadoc generated documentation. Changes from the original 
source code are bolded. 

* The main CAPS window. 

* 

* @author Ilker DURANLIOGLU, modified by Gary Kreeger 
*@versionl.i 

♦/ 

package caps.CAPSMain; 

import java.awt.*; 
import j avax. swing. *; 
import java.io.File; 
import caps.Builder.PsdlBuilder; 
import caps.Psdl.Vertex; 
import caps.Psdl.DataTypes; 
import caps.GraphEditor.Editor; 
import java.awt.e vent. *; 
import java.util. Vector; 
import j ava.util.Enumeration; 
import DistributedCaps.*; 

public class CAPSMainWindow extends JFrame { 

* The width of the frame. 

*/ 

private final int WIDTH = 400; 


* The height of the frame. 

*/ 

private final int HEIGHT = 150; 

* The File that contains the PSDL prototype, 
private File prototype; 
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fic-k 

* The object reference to the CAPS server. 

*/ 

private DistCaps capsRef; 

f** 

* The Vector that holds references to the open prototypes 
*/ 

private static Vector openPrototypes; 


//THE FOLLOWING ATTRIBUTES WERE SUGGESTED BY PROFESSOR SHING 

* The private attribute for holding protoName. 

*/ 

private static String protoName; 

Jit-k 

* The private attribute for holding protoVersion. 

*/ 

private static String protoVersion; 

jkit 

* The private attribute for holding capsUser. 

*/ 

private static String capsUser; 

* The constructor for this class. 

* 

* @param obJRef The reference to the CAPS object on the server 
♦/ 

public CAPSMainWindow (DistCaps objRef) 

{ 

super ("HSI Designer Mode"); // The title of the frame, 

prototype = null; 

capsRef = objRef; //reference to server object 

capsUser = System.getProperty("CAPSUser"); // session user 

openPrototypes = new Vector (0, 2); 
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initialize 0; 


} 


/** 

* Initializes the CAPS main window. 

*1 

public void initialize 0 

{ 

setDefaultCloseOperation(WindowConstants.DO_NOTHING_ON_CLOSE); 
addWindowListener (new ExitCAPSMain (this)); 

//Places the frame in the upper-right comer of the screen 

Dimension screenSize = Toolkit.getDefaultToolkit0.getScreenSizeO; 
setLocation(screenSize.width - (WIDTH + WIDTH / 2), HEIGHT / 2); 

setResizable (false); 

setJMenuBar (new CAPSMainMenuBar (this)); 

JPanel panel = new JPanel 0; 

JLabel capsLabel = new JLabel ("Heterogeneous System Integrator"); 
capsLabel-setFont (new Font ("Courier", FontBOLD, 17)); 

JLabel imageLabel = new JLabel (new Imagelcon ("caps/Images/caps.gif)); 

panel.add (Box.createHorizontalStrat (5)); 

panel.add (imageLabel); 

panel.add (Box.createHorizontalStmt (5)); 

panel.add (capsLabel); 

panel.add (Box.createHorizontalStrat (5)); 

getContentPane O-add (panel); 

pack 0; 

setVisible (true); 

} 


/** 

* Sets the prototype file to the argument. 

♦ 

* @param f The File that contains the PSDL prototype. 
*/ 

public void setPrototype (File f) 

{ 

prototype = f; 

} 
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J** 

* Sets the label to the string message passed in. 

* 

* @param msg The message to be displayed. 


public void setLabel (String msg) 
{ 


} 


JOptionPane.showMessageDialog (this, msg, "Information Message", 
JOptionPane.INFORMATION_MESSAGE); 


* Retrieves the curent prototype file. 

♦ 

* @retiim the File that contains the PSDL prototype. 
*/ 

public File getPrototype 0 

{ 

return prototype; 

} 


I* 4c 

* Retrieves the curent reference to the caps server. 

4c 

* @return the reference to the caps server object. 

*/ 

public DistCaps getCapsRef Q 

{ 

return capsRef; 

} 

I** 

* Returns the vector that holds the open prototype files. 

* @retum the vector that contains the open prototype files. 
*/ 

public Vector getOpenPrototypes 0 

{ 

return openPrototypes; 

} 


J4c4c 

* Sets the prototype name to the argument 

4c 

* @param name The string that contains the prototype’s name 

*/ 

public void setProtoName (String name) 
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{ 

protoName = name; 

} 


fit* 

* Sets the prototype version to the argument 

* 

@param version The string that contains the prototype’s version 

*/ 

public void setProtoVersion (String version) 

{ 

protoVersion = version; 

} 


* Gets the prototype name 

* 

*/ 

public String getProtoName 0 

{ 

return protoName; 

} 


* Gets the prototype version 

* 

*/ 

public String getProtoVersion 0 

{ 

return protoVersion; 

} 

I’k-k 

* Gets the capsUser 

* 

*/ 

public String getCapsUser Q 

{ 

return capsUser; 

} 


* Opens the graphics editor to edit a prototype. 

*/• 

public void editPrototype 0 
{ 

if (prototype = null) { // No prototype is selected to open 

JOptionPane.showMessageDialog (this, "No prototype is selected to edit.". 
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"Error Message", JOptioiiPane.ERROR_MESSAGE); 

} 

else if (lisPrototypeChanged 0) { H Attempt to edit the same prototype. 
JOptionPane.showMessageDialog (this, new String ("Prototype" + prototype.getName () + 
" is already open."), 

"Error Message", JOptionPane.ERROR_MESSAGE); 

} 

else { 

PsdlBuilder.disable_tracing 0; H Disable debug messages 
Vertex root = null; 

root = PsdlBuilder.buildPrototype (prototype); 
if (root == null) { 

root = new Vertex (0, 0, null, false); // If this is a new prototype 
String name = prototype.getName 0; H Prototype name is the same as 
root.setLabel (name.substring (0, name.length 0 - 5)); // the file name 

} 

DataTypes types = new DataTypes (); 
lypes.buildTypes (prototype); 

Editor e = new Editor (prototype, root, types); 
new Thread (e).start 0; 
openPrototypes.addElement (e); 

} 

} 


/*♦ 

* Checks whether or not the current prototype file is already used by 

* a PSDL Editor. 

* 

* @retum true if selected prototype is not already open 

* 

*/ 

public boolean isPrototypeChanged 0 

{ 

for (Enumeration enum = openPrototypes.elements (); enum.hasMoreElements ();) { 
Editor e = (Editor) enum.nextElement 0; 
if (prototype.equals (e.getPrototypeFile ())) 
return false; 

} 

return true; 

} 


* Removes one element from the openPrototypes vector. 

♦ 

* @param e the editor that is going to be removed from the vector. 
*/ 

public static void removeEditor (Editor e) 

{ 

openPrototypes.removeElement (e); 

} 


/** 
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* Checks if the status of any of the open prototypes is 'saveRequired'. 

* Prompts the user to save the prototype. 

* 

* @retum true if none of the prototypes need saving. 

*/ 

public boolean isOpenPrototypeSaved 0 

{ 

boolean flag = true; 

Editor e; 
label: 

for (Enumeration enum = openPrototypes.elements 0;enum.hasMoreElements ();) { 
e - (Editor) enum.nextElement 0; 
if (e.isSaveRequired 0) { 

int ix = JOptionPane.showConfirmDialog (this, new String ("Save changes to the prototype " + 
e.getRoot ().getLabel () + "?")); 
if (ix == JOptionPane.CANCEL_OPTION) { 
flag = false; 
break label; 

} 

else if (ix = JOptionPane.YES OPTION) 
e.savePrototype (); 

} 

} 

return flag; 

} 

} // End of the class CAPSMainWindow 


* This class holds the *Exec Support' menu items. 

* 

* @author Ilker DURANLIOGLU, modified by Gary Kreeger 

* 

* ©version 1.1 
*/ 

package caps.CAPSMain; 

import javax.swing,JMenu; 
import javax.swing.JMenuItem; 
import java.awt. event. ActionEvent; 
import java.awt.event.ActionListener; 
import java.awt.*; 
import java.io.IOException; 
import javax.swing.*; 
import java.io.*; 
import DistributedCaps.*; 

public class ExecSupportMenu extends JMenu implements ActionListener { 

* Initiates the 'Translate' event 
*/ 

private JMenuItem translateMenuItem = new JMenuItem ("Translate"); 
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/*♦ 

* Initiates the ’Schedule’ event 
*/ 

private JMenuItem scheduleMenuItem = new JMenuItem (’’Schedule”); 

* Initiates the ’Compile' event 
♦/ 

private JMenuItem compileMenuItem = new JMenuItem (’’Compile"); 

* Initiates the ’Execute’ event 

V 

private JMenuItem executeMenuItem = new JMenuItem ("Execute”); 
/*♦ 

* The main window which owns this menu, 

V 

protected CAPSMainWindow ownerWindow; 


I** 

* Constructor for this class. 

* @param owner CAPSMainWindow that owns the menu 
V 

public ExecSupportMenu (CAPSMainWindow owner) 

{ 

super ("Exec Support”); 

ownerWindow = owner; 

add (translateMenuItem); 
add (scheduleMenuItem); 
add (compileMenuItem); 
add (executeMenuItem); 


//Register the action listeners 

translateMenuItem.addActionListener (this); 
scheduleMenuItem.addActionListener (this); 
compileMenuItem.addActionListener (this); 
executeMenuItem.addActionListener (this); 

} // end of ExecSupportMenu constructor 

* Action event handler for the menu events. 

♦ 

* @param e The action event that is created by selecting a menu item 
*/ 

public void actionPerformed(ActionEvent e) 

{ 
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if (e.getSource 0 = translateMenuItem) { 

if (ownerWindow.getPrototypeO — null) // No prototype is selected to open 

{ 

JOptionPane.showMessageDialog(ownerWindow, 

"No prototype is selected to edit.", "Error Message", JOptionPane.ERROR_MESSAGE); 

} 

else 

{ 

try 

{ 

File proto = ownerWindow-getPrototypeQ; 

FilelnputStream in = new FileInputStream (proto); 
byte[] fileBuf = new byte[in.availableO]; 
in.read (fileBuf); 

DistCaps capsRef=ownerWindow.getCapsRefQ; 

String returnMsg = capsRef.translate(fileBuf, ownerWindow.getProtoNameQ, 
ownerWindow.getProtoVersionO, ownerWindow.getCapsUserO); 

ownerWindow.setLabel (returnMsg); 

System.outprintln (returnMsg); 


} 

catch (Exception el) 

{ 

System.err.println ("Error: " + el); 
el.printStackTrace (System.out); 

} 


} 

} 

else if (e.getSource 0 — scheduleMenuItem) { 
System-outprintln ("Schedule has not been implemented yet"); 

} 

else if (e.getSource 0 = compileMenuItem) { 

System.out.printto ("Compile has not been implemented yet"); 

} 

else if (e.getSource 0 = executeMenuItem) { 

System.out.println ("Executing telnet"); 
try { 

Runtime run = Runtime.getRuntime 0; 
run.exec ("telnet.exe"); 

} catch (lOException ex) { 

System.out.prmtln (ex); 

} 

} 

}// end of actionPerformed 
} // End of the class ExecSupportMenu 
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* This class holds the 'Prototype* menu items. 

♦ 

* @author Ilker DURANLIOGLU, modified by Gary Kreeger 

* @version 1.1 
♦/ 

package caps.CAPSMain; 
import javax.swing. *; 

import javax.swing.filechooser.FileSystemView; 

import java.awt.*; 

import java.awt.event.ActionEvent; 

import java.awt.event.ActionListener; 

import java.io.File; 

import java.io.*; 

import java.util. Vector; 

import DistributedCaps.*; 

public class PrototypeMenu extends JMenu implements ActionListener { 

* Initiates the *New’ event 
V 

private JMenuItem newMenuItem = new JMenuItem ("New"); 


* Initiates the 'Open* event 
*/ 

private JMenuItem openMenuItem = new JMenuItem ("Open"); 

/♦♦ 

* Initiates the 'Commit Work* event 

V 

private JMenuItem commitWorkMenuItem = new JMenuItem ("Commit Work"); 

* Initiates the 'Retrieve From DDB* event 
*/ 

private JMenuItem retrieveMenuItem = new JMenuItem ("Retrieve From DDB"); 

I** 

* Initiates the 'Quit' event 

V 

private JMenuItem quitMenuItem = new JMenuItem ("Quit"); 
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* The main window which owns this menu. 

*/ 

protected CAPSMainWindow ownerWindow; 


/** 

* Constructor for this class. 

♦ 

* @param owner The main window which has created this menu. 
*/ 

public PrototypeMenu (CAPSMainWindow owner) 

{ 

super ("Prototype”); 

ownerWindow = owner; 

add (newMenuItem); 
add (openMenuItem); 
add (commitWorkMenuItem); 
add (retrieveMenuItem); 
add (quitMenuItem); 

//Register the action listeners 

newMenuItem.addActionListener (this); 
openMenuItem.addActionListener (this); 
commitWorkMenuItem.addActionListener (this); 
retrieveMenuItem.addActionListener (this); 
quitMenuItem.addActionListener (this); 

} // end PrototypeMenu constructor 


/** 

* Action event handler for the menu events. 

* 

* @param e The action event that is created by selecting a menu item from this menu 
*/ 

public void actionPerformed(ActionEvent e) 

{ 

if (e.getSource 0 ” newMenuItem) { 
processNewMenuItem 0; 

} 

else if (e.getSource () = openMenuItem) { 
processOpenMenuItem (); 

} 

else if (e.getSource 0 “ commitWorkMenuItem) { 
processCommitWorkMenuItemO; 

} 

else if (e.getSource 0 = retrieveMenuItem) { 

System.out.println ("Retrieve has not yet been implemented"); 
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} 

else if (e.getSource 0 “ quitMenuItem) { 

// Exit the program if all of the prototypes are saved, 
if (ownerWindow.isOpenPrototypeSaved 0 ) 
System.exit (0); 

} 

} //end of actionPerformed 


/♦* 

* Handles the event which is caused by selecting the *New' menu item. 

♦/ 

public void processNewMenuItem 0 

{ 

// The system property for the home prototype directory. 

String protoHome = System.getProperty ("PROTOTYPEHOME"); 

File protoDir; 

if (protoHome == null) { // If it is not set as a command line argument 

File homeDir = FileSystemView.getFileSystemView OgetHomeDirectory (); 
protoHome = new String (homeDir + File.separator + ".caps"); 
protoDir = new File (protoHome); 
if (IprotoDir.exists 0 ) 
protoDir .mkdir Q; 

} 

else { 

protoDir - new File (protoHome); 
if (IprotoDir.exists ()) 
protoDir.mkdir (); 

} 

String proto = JOptionPane.showInputDialog (ownerWindow, 

"Enter Prototype Name : ”, "New”, JOptionPane.PLAIN_MESSAGE); 
if (proto = null) 
return; 

String version = JOptionPane.showInputDialog (ownerWindow, 

"Prototype Version Information : ",”New", JOptionPane.PLAIN_MESSAGE); 

{ 

String name = proto; 

File file = new File (protoHome + File.separator + proto + File.separator + version + 

File.separator + name + ".psdl"); 
if (file.exists 0) { 

int selected = JOptionPane.showConfirmDialog (ownerWindow, "Selected prototype file already exists.\n" + 

"Do you want to overwrite it ?"); 
if (selected = JOptionPane.YES_OPTION) { 
try { 

file.delete 0; 
file.createNewFile 0; 

} catch (java.io.IOException ex) { 

System.out.println (ex); 

} 

ownerWindow.setPrototype (file); 

} 

} 
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} 


else { 
tiy { 


File dir = file.getParentFile O-getParentFile 0; 
dir.nikdir 0; 

File vers = file.getParentFile (); 
vers.mkdir 0; 
file.createNewFile 0; 

} catch (java.io.IOException ex) { 
System.out.println (ex); 

} 

ownerWindow.setPrototype (file); 
ownerWindow.setProtoName (proto); 
ownerWindow. setProto V ersion (version); 

} 

} 

// end of processNewMenuItena 


fie* 

* Handles the event which is caused by selecting the 'Open’ menu item. 

*/ 

public void processOpenMenuItem 0 

{ 

Object[] possibleValues = { "Local", "Remote"}; 

String selectedValue = (String) JOptionPane.showInputDialog(nulI, 

"Please choose the prototype source", "Input", 

JOptionPane.INFORMATION_MESSAGE, null, possibleValues, possibleValues[0]); 

if (selectedValue == "Local") 

{ 

String protoHome = System.getProper(y ("PROTOTYPEHOME"); 

File protoDir; 

if (protoHome == null) // If it is not set as a command line argument 

{ 

File homeDir = FileSystemView.getFileSystemView 0-getHomeDirectory 0; 
protoHome = new String (homeDir + File.separator + ".caps"); 
protoDir = new File (protoHome); 
if (IprotoDir.exists 0) 

{ 

protoDir.mkdir 0; 

} 

} 

else 

{ 

protoDir = new File (protoHome); 
if (IprotoDir.exists 0) 
protoDir.mkdir 0; 

} 

Vector prototypeNames = new Vector (0,2); 

File [] dirs = protoDir.listFiles 0; 

String protoName = 


if (dirs.length = 0) 

{ 
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JOptionPane.showMessageDialog (ownerWindow, "No prototype is is found to open", 

"Error Message", JOptionPane.ERROR_MESSAGE); 

} 

else 

{ 

for (int ix = 0; ix < dirs.length; ix-H-) 

{ 

protoName = dirs [ix].getName 0; 

File subDirs [] = dirs [ix].listFiles 0; 
for (int jx = 0; jx < subDirs.length; jx-H-) 

{ 

prototypeNames.addElement (protoName.concat 
(File.separator + subDirs [jxJ.getName ())); 

} 

} 

} 

Object [] protos = prototypeNames.toArray (); 

String selected = (String) JOptionPane.showInputDialog (ownerWindow, "Select a protoype ;", 
"Open", JOptionPane.INFORMATION_MESSAGE, null, protos, protos [0]); 

if (selected != null) 

{ 

File selectedDir = new File (protoHome + File.separator + selected); 

File file = new File (selectedDir.getAbsolutePath 0 + File.separator + 
selectedDir.getParentFile OgetName () + ".psdl"); 
if (Ifile.exists 0) 

{ 

JOptionPane.showMessageDialog (ownerWindow, 

"The selected prototype file cannot be opened", 

"Error Message", JOptionPane.ERRORMESSAGE); 

} 

ownerWindow.setPrototype (file); 

ownerWindow.setProtoName (selectedDir.getParentFile O-getName ()); 
ownerWindow.setProtoVersion (selectedDir.getName 0); 

} 

} 

else // open prototype from remote source 

{ 

DistCaps capsRef = ownerWIndow.getCapsRefQ; 

//get the list of available prototypes 

String [] proto_list = capsRef.get_proto_list(ownerWindow.getCapsUserO); 
byte[] proto_fiIe; 

String selected = (String) JOptionPane.showInputDialog (ownerWindow, 

"Select a protoype : ", "Open", 
JOptionPane.INFORMATION_MESSAGE, null, 
proto_list, proto_list [0]); 


try 

{ 

//open the selected file from the remote server 

proto_file = capsRef.open_proto (selected, ownerWindow.getCapsUserO); 
if (proto_file == null) 
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{ 

JOptionPane.showMessageDiaIog (ownerWindow, 

"The selected prototype file cannot be opened", 

"Error Message", JOptionPane.ERROR_MESSAGE); 

} 

else 

{ 

try //convert the selected file from a byte array back to a file 

{ 

String protoHome = System.getProperty ("PROTOTYPEHOME"); 

File protoDir; 

if (protoHome = null) // If it is not set as a command line argument 

{ 

File homeDir = FileSystemView.getFileSystemView 0*gctHomeDirectory Q; 
protoHome = new String (homeDir + File.separator + ".caps"); 
protoDir = new File (protoHome); 
if (IprotoDir.exists 0) 

{ 

protoDir.mkdirs 0; 

} 

} 

else 

{ 

protoDir = new File (protoHome); 
if (IprotoDir.exists 0) 

{ 

protoDir.mkdirs 0; 

} 

} 

File selectedDir = new File (protoHome + File.separator + selected); 
if (IselectedDir.exists 0) 

{ 

selectedDir.mkdirs 0; 

} 

else 

{ 

ownerWindow.setLabel ("The remote file will overwrite an existing local one" 

} 

File file = new File (selectedDir.getAbsolutePath Q + File.separator + 
selectedDir.getParentFile 0-getName 0 + ’Vpsdl"); 
boolean tempBoolean = file.createNewFileO; 

FileOutputStream fos = new FileOutputStream (file); 

fos. write (proto_file); 

fos.closeO; 

ownerWindow.setPrototype (file); 

ownerWindow.setProtoName (selectedDir.getParentFile Q-getName 0); 
ownerWindow.setProtoVersion (selectedDir.getName 0); 

} 

catch (Exception e) 

{ 

JOptionPane.showMessageDiaIog (ownerWindow, 

"The selected prototype file was retrieved but cannot be opened", 

"Error Message", JOptionPane.ERROR__MESSAGE); 
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Systein.out.pnntln (e); 

} 

} 

} 

catch (DistributedCaps.DistCapsPackage.cantReadFile e2) 

{ 

JOptionPane.showMes$ageDialog (ownerWindow, 

*'The selected prototype file cannot be opened", 

"Error Message", JOptionPane.ERROR_MESSAGE); 
System.outprintln (e2); 

} 

} 

}//End of processOpenMenuItem 


* Handles the event which is caused by selecting the 'Commif menu item. 

*/ 

public void processCommitWorkMenuItem 0 

{ 

setCursor (new Cursor(Cursor.WAIT_ClJRSOR)); 

File proto = ownerWindow.getPrototypeQ; 

String protoName = ownerWindow.getProtoNameQ; 

if ( protoName == null) // No prototype is selected to open 

{ 

JOptionPane-showMessageDialog (ownerWindow, 

"No prototype is selected.", "Error Message", JOptionPane.ERROR_MESSAGE); 

} 

else 

{ 

if (ownerWindow.isOpenPrototypeSaved 0) 

{ 

try //convert the file to a byte array for transfer to the server 

{ 

FileInputStream in = new FileInputStream (proto); 
byte[] fileBuf = new byte[in.availableO]; 
in.read (fileBuf); 

DistCaps capsRef = ownerWindow.getCapsRefQ; 

String returnMsg = capsRef.commit(fileBuf, protoName, 
ownerWindow.getProtoVersionO? ownerWindow.getCapsUserO); 

ownerWindow.setLabel (returnMsg); 

System.outprintln (returnMsg); 


} 

catch (Exception el) 

{ 

System.err.println ("Error: " + el); 
el.printStackTrace (System.out); 


} 

} 

else 
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{ 

ownerWindow.setLabel ("You must save the prototype before committing it"); 

} 

setCursor (new Cursor(Cursor.DEFAULT_CURSOR)); 

} //end of processCommitWorkMenuItem 

} // End of the class PrototypeMenu 
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Class 


Tree Deprecated Index Help 

PREV CLASS NEXT CLASS FRAMES NO FRAMES 

SUMMARY: INNER 1 FIELD | CONSTR | METHOD DETAIL: FIELD | CQ.NSJR | METH O D 


caps.CAPSMain 

Class CAPSMainWindow 

java.lang.Object 

I 

+—java.awt.Component 

I 

+—j ava.awt.Container 

I 

+--j ava.awt.Window 

I 

+—j ava.awt.Frame 

I 

+—javax.swing.JFrame 

I 

+—caps.CAPSMain.CAPSMainWindow 


public class CAPSMainWindow 
extends javax.swing.JFrame 

The main CAPS window. 

See Also: 

Serialized Form 


_______^-—- 1 

Inner classes inherited from class ja vax.swing. JFrame _ 

javax. swing. JFrame. Accessible JFrame ___ 


Inner classes inherited from class java.awt.Component 

j ava.awt.Component.AWTTreeLock 
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Field Summary j 

private 

DistributedCaps.DistCaps 

capsRef 

The object reference to the CAPS server. 

private 

static java.lang.String 

capsUser 

The private attribute for holding capsUser. 

private. int 

HEIGHT 

The height of the frame. 

private 

static java.util.Vector 

openPrototypes 

The Vector that holds references to the open prototypes 

private 

static java.lang.String 

protoName 

The private attribute for holding protoName. 

private java.io.File 

prototype 

The File that contains the PSDL prototype. 

private 

static java.lang.String 

protoVersion 

The private attribute for holding protoVersion. 

private int 

WIDTH 

The width of the frame. 


Fields inherited from class javax.swing.JFrame 

accessibleContext, defaultCloseOperation, rootPane, rootPaneCheckingEnabled 


Fields inherited from class java.awtFrame 

base, CROSSHAIR_CURSOR, DEFAULT_CURSOR, E_RESIZE_CURSOR, frameSerializedDataVersion, 
HAND_CURSOR, icon, ICONIFIED, mbManagement, menuBar, MOVE_CURSOR, N_RESIZE_CURSOR, 
nameCounter, NE_RESIZE_CURSOR, NORMAL, NW_RESIZE_CURSOR, ownedWindows, resizable, 
S_RESIZE_CURSOR, SE_RESIZE_CURSOR, serialVersionUID, state, SW_RESIZE_CURSOR, 

TEXT CURSOR, title, W_RESIZE_CURSOR, WAIT_CURSOR, weakThis 


Fields inherited from class java.awt.Window 


active, base, focusMgr, inputContext, nameCounter, OPENED, ownedWindowList, 
serialVersionUID, state, warningstring, weakThis, windowListener, 
windowSerializedDataversion 



Fields inherited from class java.awtContainer 

component, containerListener, containerSerializedDataVersion, dispatcher, layoutMgr, 
maxSize, ncomponents, serialVersionUID 
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Fields inherited from cl ass java.awt.Component ____ 

actionListenerK, adjustmentListenerK, appContext, assert, background, 

BOTTOM ALIGNMENT, CENTER_ALIGNMENT, changeSupport, componentListener, ^ 
componentListenerK, componentOrientation, componentSeriaLizedDataVersion, 
containerListenerK, cursor, dropTarget, enabled, eventMask, focusListener, 
focusListenerK, font, foreground, hasFocus, height, incRate, inputMethodListener, 
inputMethodListenerK, isinc, isPacked, itemListenerK, keyListener, keyListenerK, 
LEFT ALIGNMENT, locale, LOCK, minSize, mouseListener, mouseListenerK, ^ 
mouseMotionListener, mouseMotionListenerK, name, nameExplicitlySet, newEventsOnly, 
ownedWindowK, parent, peer, peerFont, popups, prefSize, RIGHT_ALIGNMpT, 
serialVersionUID, textListenerK, TOP_ALIGNMENT, valid, visible, width, 
windowListenerK, x, y _____—_ 


Constructor Summary __ 

CAPSMainWindow (DistributedCaps.DistCaps objRef) 

The constructor for this class. 


Method Summary 

void 

editPrototype () 

Opens the graphics editor to edit a prototype. 

DistributedCaps.DistCaps 

getCapsRef() 

Retrieves the curent reference to the caps server. 

java.lang.String 

getCapsUser() 

Gets the capsUser 

java.util.Vector 

getOpenPrototypes() 

Returns the vector that holds the open prototype files. 

java.lang.String 

getProtoName{) 

Gets the prototype name 

j ava.io.File 

getPrototype () 

Retrieves the curent prototype file. 

java.lang.String 

getProtoVersion () 

Gets the prototype version 

void 

initialize {) 

Initializes the CAPS main window. 

boolean 

isOpenPrototypeSaved( ) 

Checks if the status of any of the open prototypes is 'saveRequired. 

boolean 

isPrototvpeChanged () 

Checks whether or not the current prototype file is already used by a 

PSDL Editor. 

static void 

removeEditoiT ( caps . GraphEditor. Edi uor* e ) 

Removes one element from the openPrototypes vector. 

void 

setLabeKjava.lang.string msg) 

Sets the label to the string message passed in. 

void 

setProtoName ( java.lang.String name) 
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^iets tne prototype name to tne argument 


void 

setPrototype(java.io.File f) 

Sets the prototype file to the argument. 

void 

setProtoVersion(iava.lanq.String version) 

Sets the prototype version to the argument 


Methods inherited from class javax.swing.JFrame 

addlmpl, createRootPane, createRootPaneException, framelnit, getAccessibleContext, 
getContentPane, getDefaultCloseOperation, getGlassPane, getJMenuBar, getLayeredPane, 
getRootPane, isRootPaneCheckingEnabled, paramString, processKeyEvent, 
processWindowEvent, remove, setContentPane, setDefaultCloseOperation, setGiassPane, 
setJMenuBar, setLayeredPane, setLayout, setRootPane, setRootPaneCheckingEnabled, 
update 


Methods inherited from class java.awt.Frame 

, addNotify, addToFrameList, constructComponentName, finalize, getCursorType, 
getFrames, geticonimage, getMenuBar, getState, getTitle, initIDs, isResizable, 
postProcessKeyEvent, readObject, remove, removeFromFrameList, removeNotify, 
setCursor, seticonimage, setMenuBar, setResizable, setState, setTitle, writeObject 


Methods inherited from class java.awt.Window 

addOwnedWindow, addWindowListener, applyResourceBundle, applyResourceBundle, 
connectOwnedWindow, dispatchEventlmpl, dispose, eventEnabled, getFocusOwner, 
getInputContext, getLocale, getOwnedWindows, getOwner, getToolkit, getWarningString, 
hide, isActive, isShowing, nextFocus, ownedinit, pack, postEvent, postWindowEvent, 
preProcessKeyEvent, processEvent, removeOwnedWindow, removeWindowListener, 
setCursor, setFocusOwner, setWarningString, show, toBack, toFront, transferFocus 


Methods inherited from class java,awtContainer 

add, add, add, add, add, addContainerListener, applyOrientation, countComponents, 
deiiverEvent, dispatchEventToSelf, doLayout, findComponentAt, findComponentAt, 
getAlignmentX, getAlignmentY, getComponent, getComponentAt, getComponentAt, 
getComponentCount, getComponents_NoClientCode, getComponents, getCursorTarget, 
getinsets, getLayout, getMaximumSize, getMinimumSize, getMouseEventTarget, 
getPreferredSize, getWindow, insets, invalidate, invalidateTree, isAncestorOf, 
layout, lightweightPrint, list, list, locate, minimumSize, paint, paintComponents, 
postsOldMouseEvents, preferredSize, print, printComponents, printOneComponent, 
processContainerEvent, proxyEnableEvents, proxyRequestFocus, remove, removeAll, 
removeContainerListener, setFont, updateCursor, validate, validateTree 
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Methods inherited from class java.awt.Component_____ 

action, add, addComponentListener, addFocusListener, addInputMethodListener, 
addKeyListener, addMouseListener, addMouseMotionListener, addPropertyChangeListener, 
addPropertyChangeListener, areInputMethodsEnabled, bounds, checkimage, checkimage, 
coalesceEvents, contains, contains, createlmage, createlmage, disable, 
disableEvents, dispatchEvent, enable, enable, enableEvents, enableInputMethods, 
firePropertyChange, getBackground, getBounds, getBounds, getColorModel, 
getComponentOrientation, getCursor, getDropTarget, getFont_NoClientCode, getFont, 
getFontMetrics, getForeground, getGraphics, getHeight, getInputMethodRequests, 
getIntrinsicCursor, getLocation, getLocation, getLocationOnScreen, getName, 
getNativeContainer, getParent_NoClientCode, getParent, getPeer, getSize, getSize, 
getToolkitlmpl, getTreeLock, getWidth, getWindowForObject, getX, getY, gotFocus, 
handleEvent, hasFocus, imageUpdate, inside, isDisplayable, isDoubleBuffered, 
isEnabled, isEnabledlmpl, isFocusTraversable, isLightweight, isOpaque, isValid, 
isVisible, keyDown, keyUp, list, list, list, location, lostFocus, mouseDown, 
mouseDrag, mouseEnter, mouseExit, mouseMove, mouseUp, move, nextFocus, paintAll, 
preparelmage, preparelmage, printAll, processComponentEvent, processFocusEvent, 
processInputMethodEvent, processMouseEvent, processMouseMotionEvent, 
removeComponentListener, removeFocusListener, removeInputMethodListener, 
removeKeyListener, removeMouseListener, removeMouseMotionListener, 
removePropertyChangeListener, removePropertyChangeListener, repaint, repaint, 
repaint, repaint, requestFocus, reshape, resize, resize, setBackground, setBounds, 
setBounds, setComponentOrientation, setDropTarget, setEnabled, setForeground, 
setLocale, setLocation, setLocation, setName, setSize, setSize, setVisible, show, 
size, toString, transferFocus _ 


Methods inherited fro m class java.lang.Object __ 

clone, equals, getClass, hashCode, notify, notifyAll, registerNatives, wait, wait, 
wait 


Field DetaU 


WIDTH 

private final int WIDTH 

The width of the frame. 


HEIGHT 

private final int HEIGHT 

The height of the frame. 


prototype 

private java.io.File prototype 

The File that contains the PSDL prototype. 
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capsRef 

private DistributedCaps.DistCaps capsRef 
The object reference to the CAPS server. 


protoName 

private static java.lang.String protoName 
The private attribute for holding protoName. 


protoVersion 

private static java.lang.String protoVersion 
The private attribute for holding protoVersion. 


capsUser 

private static java.lang.String capsUser 
The private attribute for holding capsUser. 


openPrototypes 

private static java.util.Vector openPrototypes 

The Vector that holds references to the open prototypes 

Constructor Detail 

CAPSMainWindow 

public CAPSMainWindow(DistributedCaps.DistCaps objRef) 

The constructor for this class. 

Parameters: 

Ob j Ref - The reference to the CAPS object on the server 
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Method Detail 


initialize 

public void initialize() 

Initializes the CAPS main window. 


setPrototype 

public void setPrototype(java,io.File f) 

Sets the prototype file to the argument. 

Parameters: 

f - The File that contains the PSDL prototype. 


setLabel 

public void setLabel(java.lang.String msg) 

Sets the label to the string message passed in. 

Parameters: 

msg - The message to be displayed. 


getPrototype 

public java.io.File getPrototype{) 

Retrieves the curent prototype file. 

Returns: 

the File that contains the PSDL prototype. 


getCapsRef 

public DistributedCaps.DistCaps getCapsRef() 

Retrieves the curent reference to the caps server. 
Returns: 

the reference to the caps server object. 


getOpenPrototypes 
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public java.util.Vector getOpenPrototypes() 

Returns the vector that holds the open prototype files. 

Returns: 

the vector that contains the open prototype files. 


setProtoName 

public void setProtoName(java.lang.String name) 

Sets the prototype name to the argument 
Parameters: 

name - The String that contains the prototype's name 


setProtoVersion 

public void setProtoVersion(java.lang.String version) 

Sets the prototype version to the argument 
Parameters: 

version - The String that contains the prototype's version 


getProtoName 

public java.lang.String getProtoName{) 
Gets the prototype name 


getProtoVersion 

public java.lang.String getProtoVersion{) 
Gets the prototype version 


getCapsUser 

public java.lang.String getCapsUser() 

Gets the capsUser 
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editPrototype 

public void editPrototype() 

Opens the graphics editor to edit a prototype. 


isPrototypeChanged 

public boolean isPrototypeChanged() 

Checks whether or not the current prototype file is already used by a PSDL Editor. 

Returns: 

true if selected prototype is not already open 


removeEditor 

public static void removeEditor(caps.GraphEditor.Editor e) 

Removes one element from the openPrototypes vector. 
Parameters: 

e - the editor that is going to be removed from the vector. 


isOpenPrototypeSaved 

public boolean isOpenPrototypeSaved() 

Checks if the status of any of the open prototypes is 'saveRequired'. Prompts the user to save the 
prototype. 

Returns: 

true if none of the prototypes need saving. 


Class 


Tree Deprecated Index Help 


PREV CLASS NEXT CLASS 
SUMMARY: INNER | FIELD | CONSTR | METHOD 


FRAMES NO FRAMES 

DETAIL: FIELD I CONSTR i METHOD 
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Class 


Tree Deprecated Index Help 

PREV CLASS NEXT CLASS FRAMES NO FRAMES 

SUMMARY: INNER | FIELD | CONSTR ] METHOD DETAIL: FIELD | CONSTR | METHOD 


caps.CAPSMain 

Class ExecSupportMenu 

j ava.lang.Obj ect 
I 

+—java.awt.Component 

I 

+—j ava.awt.Container 
I 

+—j avax.swing.JComponent 

I 

+—javax.swing.AbstractButton 

I 

+—j avax.swing.JMenuItem 

I 

+—javax.swing.JMenu 
I 

+--oaps.CAPSMain.ExecSupportMenu 


public class ExecSupportMenu 
extends javax.swmg. JMenu 
implements java.avvt.event.ActionListener 

This class holds the 'Exec Support' menu items. 

See Also: 

Serialized Form 


Inner classes inherited from class javax.swing. JMenu 

j avax. swing. JMenu. Accessible JMenu, j avax. swing. JMenu. MenuChangeLis tener, 
j avax.swing.JMenu.WinLis tener 


Inner classes inherited from class javax.swing.JMenuItem 

javax. swing. JMenuItem. Accessible JMenuItem 


Inner classes inherited from class javax.swing.AbstractButton 

javax. swing, AbstractButton.AccessibleAbstractButton, 
javax. swing. AbstractButton. ButtonChangeListener 
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Inner classes inherited from class javax.swi ng.JComponent _ 

j avax,swing.JComponent.AccessibleJComponent , j avax.swing.JComponent.IntVector, 
javax.swing.JComponent.KeyboardBinding, javax.swing.JComponent.Keyboardstate 


Inner classes inherited from class java.awt.Component 

java.awt.Component. AWTTreeLock 


Field Summary 

private javax.swing.JMenuItem 

compi1eMenuItern 

Initiates the 'Compile' event 

private javax.swing.JMenuItem 

executeMenuItern 

Initiates the 'Execute' event 

protected 

caps.CAPSMain.CAPSMainWindow 

ownerWindow 

The main window which owns this menu. 

private javax.swing.JMenuItem 

s chedul eMenu I tern 

Initiates the 'Schedule' event 

private javax.swing.JMenuItem 

translateMenuItern 

Initiates the 'Translate' event 


Fields inherited from class javax.swing.J Menu _ 

delay, listenerRegistry, menuChangeListener, menuEvent, popupListener, popupMenu, 
uiClassID _. 


Fields inherited from class javax.swing.JMenuItem 

accelerator, uiClassID 


Fields inherited from class j avax.swing. AbstractButton_ 

actionListener, BORDER_PAINTED_CHANGED_PROPERTY, changeEvent, changeListener, 
CONTENT_AREA_FILLED_CHANGED_PROPERTY, contentAreaFilled, defaulticon, defaultMargin, 
DISABLED_ICON_CHANGED_PROPERTY, DISABLED_SELECTED_ICON_CHANGED_PROPERTY, 
disabledicon, disabledSelectedIcon, FOCUS_PAINTED_CHANGED_PROPERTY, 

HORIZONTAL ALIGNMENT_CHANGED_PROPERTY, HORIZONTAL_TEXT_POSITION_CHANGED_PROPERTY, 
horizontalAlignment, horizontalTextPosition, ICON_CHANGED_PROPERTY, iternListener, 
margin, MARGIN CHANGED_PROPERTY, MNEMONIC_CHANGED_PROPERTY, model, 

MODEL CHANGED PROPERTY, paintBorder, paintFocus, PRESSED_ICON_CHANGED_PROPERTY, 
pressedicon, ROLLOVER_ENABLED_CHANGED_PROPERTY, ROLLOVER_ICON_CHANGED_PROPERTY, 
ROLLOVER_SELECTED_ICON_CHANGED_PROPERTY, rolloverEnabled, rollovericon, 
rolloverSelectedIcon, SELECTED_ICON_CHANGED_PROPERTY, selectedicon, text, 
TEXT_CHANGED_PROPERTY, VERTICAL_ALIGNMENT_CHANGED_PROPERTY, 

VERTICAL TEXT POSITION CHANGED PROPERTY, verticalAlignment, verticalTextPosition 
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Fields inherited from class javax.swing.JComponent 

_bounds, accessibleContext r alignmentX, alignmentY, ANCESTOR_USING_B[JFFER, 
ancestorNotifier, autoscroller, border, changeSupport, clientProperties, flags, 
HAS_FOCUS, IS_DOUBLE_BUFFERED, IS_OPAQUE, IS_PAINTING_TILE, KEYBOARD^BINDINGS^KEY, 
listenerList, maximumSize, minimumSize, NEXT_FOCUS, paintImmediatelyClip, 
paintingChild, preferredSize, readObjectCallbacks, REQUEST_FOCUS_DISABLED, tmpRect, 
TOOL_TIP_TEXT_KEY, ui, uiClassID, UNDEFINED_CONDITION, vetoableChangeSupport, 

WHEN ANCESTOR OF FOCUSED COMPONENT, WHEN FOCUSED, WHEN IN FOCUSED WINDOW 


Fields inherited from class java.awt.Container 

component, containerListener, containerSerializedDataversion, dispatcher, layoutMgr, 
maxSize, ncomponents, serialVersionUID 


Fields inherited from class java.awt.Component 

actionListenerK, adjustmentListenerK, appContext, assert, background, 
BOTTOM__ALIGNMENT, CENTER_ALIGNMENT, changeSupport, componentListener, 
componentListenerK, componentOrientation, componentSerializedDataversion, 
containerListenerK, cursor, dropTarget, enabled, eventMask, focusListener, 
focusListenerK, font, foreground, hasFocus, height, incRate, inputMethodListener, 
inputMethodListenerK, isinc, isPacked, itemListenerK, keyListener, keyListenerK, 
LEFT_ALIGNMENT, locale, LOCK, minSize, mouseListener, mouseListenerK, 
mouseMotionListener, mouseMotionListenerK, name, nameExplicitlySet, newEventsOnly, 
ownedWindowK, parent, peer, peerFont, popups, prefSize, RIGHT_ALIGNMENT, 
serialVersionUID, textListenerK, TOP_ALIGNMENT, valid, visible, width, 
windowListenerK, x, y 


Constructor Summary 

ExecSupportMenu (caps . CAPSMain. CAPSMainWindow owner) 

Constructor for this class. 


1 

Method Summary 

void 

actionPerformed(j ava.awt,event.ActionEvent e) 

Action event handler for the menu events. 


Methods inherited from class javax.swing.JMenu 

, add, add, add, add, addMenuListener, addSeparator,' buildMenuElementArray, 
clearListenerRegistry, createActionChangeListener, createMenuChangeListener, 
createWinListener, doClick, ensurePopupMenuCreated, fireMenuCanceled, 
fireMenuDeselected, fireMenuSelected, getAccessibleContext, getComponent, getDelay, 
getItern, get11emCount, getMenuComponent, getMenuComponentCount, getMenuComponents, 
getPopupMenu, getPopupMenuOrigin, getSubElements, getUIClassID, insert, insert, 
insert, insertSeparator, isMenuComponent, isPopupMenuVisible, isSelected, isTearOff, 
isTopLevelMenu, menuSelectionChanged, paramString, processKeyEvent, 
registerMenuItemForAction, remove, remove, remove, removeAll, removeMenuListener, 
setAccelerator, setDelay, setMenuLocation, setModel, setPopupMenuVisible, 
setSelected, translateToPopupMenu, translateToPopupMenu, 
unregisterMenuItemForAction, updateUI, writeObject 
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Methods inherited from class javax.swing.JMenuItem 

addMenuDragMouseListener, addMenuKeyListener, alwaysOnTop, fireMenuDragMouseDragged, 
fireMenuDragMouseEntered, fIreMenuDragMouseExited, fireMenuDragMouseReleased, 
fireMenuKeyPressed, fireMenuKeyReleased, fireMenuKeyTyped, getAccelerator, init, 
isArmed, processKeyEvent, processMenuDragMouseEvent, processMenuKeyEvent, 
processMouseEvent, readObject, removeMenuDragMouseListener, removeMenuKeyListener, 
setArmed, setEnabled, setUI 


Methods inherited from class javax.swing.AbstractButton 

addActionListener, addChangeListener, addlteiuListener, checkHorizontalKey, 
checkVerticalKey, createActionListener, createChangeListener, createltemListener, 
doClick, fireActionPerformed, fireltemStateChanged, fireStateChanged, 
getActionCommand, getDisabledIcon, getDisabledSelectedIcon, getHorizontalAlignment, 
getHorizontalTextPosition, geticon, getLabel, getMargin, getMnemonic, getModei, 
getPressedicon, getRolloverIcon, getRolloverSelectedicon, getSelectedicon, 
getSelectedObjects, getText, getUI, getVerticalAlignment, getVerticalTextPosition, 
isBorderPainted, isContentAreaFilled, isFocusPainted, isRolloverEnabled, 
paintBorder, removeActionListener, removeChangeListener, removeltemListener, 
setActionCommand, setBorderPainted, setContentAreaFilled, setDisabledIcon, 
setDisabledSelectedicon, setFocusPainted, setHorizontalAlignment, 

setHorizontalTextPosition, seticon, setLabel, setMargin, setMnemonic, setMnemonic, 
setPressedIcon, setRolloverEnabled, setRolloverIcon, setRolloverSelectedicon, 
setSelectedicon, setText, setUI, setVerticalAlignment, setVerticalTextPosition 


Methods inherited from class javax.swing.JComponent 

_paintlmmediately, addAncestorListener, addNotify, addPropertyChangeListener, 

:addPropertyChangeListener, addVetoableChangeListener, adjustPaintFlags, 
bindingForKeyStroke, checklfChildObscuredBySibling, computeVisibleRect, 
computeVisibleRect, contains, creat-ToolTip, enableSerialization, 
firePropertyChange, firePropertyChange, firePropertyChange, firePropertyChange, 
firePropertyChange, firePropertyChange, firePropertyChange, firePropertyChange, 
firePropertyChange, fireVetoableChange, getActionForKeyStroke, getAlignmentX, 
getAlignmentY, getAutoscrolls, getBorder, getBounds, getClientProperties, 
getClientProperty, getComponentGraphics, getConditionForKeyStroke, 
getDebugGraphicsOptions, getFlag, getGraphics, getHeight, getinsets, getinsets, 
getLocation, getMaximumSize, getMinimumSize, getNextFocusableComponent, 
getPreferredSize, getRegisteredKeyStrokes, getRootPane, getSize, getToolTipLocation, 
getToolTipText, getToolTipText, getTopLevelAncestor, getVisibleRect, getWidth, getX, 
getY, grabFocus, hasFocus, isDoubleBuffered, isFocusCycleRoot, isFocusTraversable, 
isLightweightComponent, isManagingFocus, isOpaque, isOptimizedDrawingEnabled, 
isPaintingTile, isRequestFocusEnabled, isValidateRoot, keyboardBindings, paint, 
paintChildren, paintComponent, paintImmediately, paintImmediately, paintWithBuffer, 
processComponentKeyEvent, processFocusEvent, processKeyBinding, processKeyBindings, 
processKeyBindingsForAllComponents, processMouseMotionEvent, putCllentProperty, 
rectangleIsObscured, rectanglelsObscuredBySibling, registerKeyboardAction, 
registerKeyboardAction, registerWithKeyboardManager, removeAncestorListener, 
removeNotify, removePropertyChangeListener, removePropertyChangeListener, 
removeVetoableChangeListener, repaint, repaint, requestDefauitFocus, requestFocus, 
resetKeyboardActions, reshape, revalidate, scrollRectToVisible, setAlignmentX, 
setAlignmentY, setAutoscrolls, setBackground, setBprder, setDebugGraphicsOptions, 
setDoubieBuffered, setFlag, setFont, setForeground, setMaximumSize, setMinimumSize, 
setNextFocusableComponent, setOpaque, setPaintingChild, setPreferredSize, 
setRequestFocusEnabled, setToolTipText, setUI, setVisible, shouldDebugGraphics, 
superProcessMouseMotionEvent, unregisterKeyboardAction, 
unregisterWithKeyboardManager, update 


154 









Methods inherited from class java.awt.Container 

add, add, add, add, addContainerListener, addlmpl, appiyOrientation, 
countComponents, deliverEvent, dispatchEventlmpl, dispatchEventToSelf, doLayout, 
eventEnabled, findComponentAt, findComponentAt, getComponent, getComponentAt, 
getComponentAt, getComponentCount, getComponents_NoClientCode, getComponents, 
getCursorTarget, getLayout, getMouseEventTarget, getWindow, initIDs, insets, 
invalidate, invalidateTree, isAncestorOf, layout, lightweightPrint, list, list, 
locate, minimumSize, nextFocus, paintComponents, postProcessKeyEvent, 
postsOldMouseEvents, preferredSize, preProcessKeyEvent, print, printComponents, 
printOneComponent, processContainerEvent, processEvent, proxyEnableEvents, 
proxyRequestFocus, removeContainerListener, setCursor, setFocusOwner, setLayout, 
transferFocus, updateCursor, validate, validateTree 


Methods inherited from class java.awt.Component 

action, add, addComponentListener, addFocusListener, addInputMethodListener, 
addKeyListener, addMouseListener, addMouseMotionListener, areInputMethodsEnabled, 
bounds, checkimage, checkimage, coalesceEvents, constructComponentName, contains, 
createlmage, createlmage, disable, disableEvents, dispatchEvent, enable, enable, 
enableEvents, enableInputMethods, getBackground, getBounds, getColorModel, 
getComponentOrientation, getCursor, getDropTarget, getFont_NoClientCode, getFont, 
getFontMetrics, getForeground, getInputContext, getInputMethodRequests, 
getIntrinsicCursor, getLocale, getLocation, getLocationOnScreen, getName, 
getNativeContainer, getParent_NoClientCode, getParent, getPeer, getSize, getToolkit, 
getToolkitlmpl, getTreeLock, getWindowForObject, gotFocus, handleEvent, hide, 
imageUpdate, inside, isDisplayable, isEnabled, isEnabledlmpl, isLightweight, 
isShowing, isValid, isVisible, keyDown, keyUp, list, list, list, location, 
lostFocus, mouseDown, mouseDrag, mouseEnter, mouseExit', mouseMove, mouseUp, move, 
nextFocus, paintAll, postEvent, preparelmage, preparelmage, printAll, 
processComponentEvent, processInputMethodEvent, processMouseEvent, remove, 
removeComponentListener, removeFocusListener, removeInputMethodListener, 
removeKeyListener, rempveMouseListener, removeMouseMotionListener, repaint, repaint, 
repaint, resize, resize, setBounds, setBounds, setComponentOrientation, 
setDropTarget, setLocale, setLocation, setLocation, setName, setSize, setSize, show, 
show, size, toString, transferFocus 


Methods inherited from class java.Ian g^Object ___ 

clone, equals, finalize, getClass, hashCode, notify, notifyAll, registerNatives, 
wait, wait, wait 


[Field DetaU __ 

transIateMenuItem 

private javax.swing.JMenuItern transIateMenuItem 

Initiates the 'Translate' event 


scheduleMenuItem 

private javax.swing.JMenuItem schedul^enultem 
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Initiates the 'Schedule' event 


com pileMen ultem 

private javax.swing.JMenuItem compileMenuItem 

Initiates the 'Compile' event 


executeMenuItem 

private javax.swing.JMenuItem executeMenuItem 

Initiates the 'Execute' event 


ownerWindow 

protected caps .CAPSMain.CAPSMainWindow ownerWindow 

The main window which owns this menu. 


Constructor Detail 


ExecSupportMenu 

public ExecSupportMenu(caps.CAPSMain.CAPSMainWindow owner) 

Constructor for this class. 

Parameters: 

owner - CAPSMainWindow that owns the menu 

Method Detail 


actionPerformed 

public void actionPerformed (java.awt.event.ActionEvent e) 

Action event handler for the menu events. 

Specified by: 

actionPerformed in interface java.awt.event.ActionListener 
Parameters: 

e - The action event that is created by selecting a menu item 


156 








Class 


Tree Deprecated Index Help 

PREV CLASS NEXT CLASS FRAMES NO FRAMES 

SUMMARY: INNER | FIELD | CONSTR | METHOD DETAIL: FIELD | CONSTR | METHOD 


caps.CAPSMain 

Class PrototypeMenu 

j ava.lang.Obj ect 
I 

+—j ava.awt.Component 
I 

+—j ava.awt.Container 
I 

+—javax.swing.JComponent 
I 

+—j avax.swing.AbstractButton 

I 

+—javax.swing.JMenuItem 

+—j avax.swing.JMenu 

I 

+—caps. CAPSMain. PrototypeMenu 

public class PrototypeMenu 

extends javax.swing. JMenu 

implements java.awt.event.ActionListener 

This class holds the 'Prototype' menu items. 

See Also: 

Serialized Fonn 


Inner classes inherited from class javax.swing.JMenu 

j avax. swing. JMenu. Accessible JMenu, j avax. swing. JMenu. MenuChangeLis tener, 
j avax.swing. JMenu. WinListener 


Inner classes inherited from class javax.swing.JMenuItem 

j avax. swing, JMenuItem. Accessible JMenuItem 


Inner classes inherited from class javax.swing.AbstractButton 

j avax.swing.Abs tractButton. AccessibleAbs tractButton, 
javax.swing.AbstractButton.ButtonChangeListener 
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Inner classes inherited from class javax.swing.JComponent 

javax. swing. JComponent. AccessibleJComponent, javax. swing. JComponent. IntVector, 
j avax.swing.JComponent.KeyboardBinding , j avax.swing.JComponent.Keyboards tate 


Inner classes inherited from class java.awt.Component 

j ava.awt.Component.AWTTreeLock 


Field Summary 

private javax.swing.JMenuItem 

commi tWorlcMenuI tern 

Initiates the 'Commit Work' event 

private javax.swing.JMenuItem 

newMenuItem 

Initiates the 'New' event 

private javax.swing.JMenuItem 

openMenuItern 

Initiates the 'Open' event 

protected 

caps.CAPSMain.CAPSMainWindow 

ownerWindow 

The main window which owns this menu. 

private javax.swing.JMenuItem 

qu i tMenu I tern 

Initiates the 'Quit' event 

private javax.swing.JMenuItem 

retr ieveMenuI tern 

Initiates the 'Retrieve From DDB' event 


Fields inherited from class javax.swing.JMenu 

delay, listenerRegistry, menuChangeListener, menuEvent, popupListener, popupMenu, 
uiClassID 


Fields inherited from class javax.swing.JMenuItem 

accelerator, uiClassID 


Fields inherited from class javax.swing.AbstractButton 

actionListener, BORDER_PAINTED_CHANGED_PROPERTY, changeEvent, changeListener, 
CONTENT_AREA_FILLED_CHANGED_PROPERTY, contentAreaFilled, defaulticon, defaultMargin, 
DISABLED_ICON_CHANGED_PROPERTY, DISABLED_SELECTED_ICON_CHANGED_PROPERTY, 
disabledicon, disabledSelectedIcon, FOCUS_PAINTED_CHANGED_PROPERTY, 
HORIZONTAL_ALIGNMENT_CHANGED_PROPERTY, HORIZONTAL_TEXT_POSITION_CHANGED_PROPERTY, 
horizontalAlignment, horizontalTextPosition, ICON_CHANGED_PROPERTY, itemListener, 
margin, MARGIN_CHANGED_PROPERTY, MNEMONIC_CHANGED_PROPERTY, model, 
MODEL_CHANGED_PROPERTY, paintBorder, paintFocus, PRESSED_ICON_CHANGED_PROPERTY, 
pressedicon, ROLLOVER_ENABLED_CHANGED_PROPERTY, ROLLOVER_ICON_CHANGED_PROPERTY, 
ROLLOVER_SELECTED_ICON_CHANGED_PROPERTY, rolloverEnabled, rolloverIcon, 
rolloverSelectedIcon, SELECTED_ICON_CHANGED_PROPERTY, selectedicon, text, 
TEXT_CHANGED_PROPERTY, VERTICAL_ALIGNMENT_CHANGED_PROPERTY, 

VERTICAL TEXT POSITION CHANGED PROPERTY, verticalA.lignment, verticalTextPosition 
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Fields inherited from class javax.swing.JComponent 

_bounds, accessibleContext, alignmentX, alignmentY, ANCESTOR_USING_BUFFER, 
ancestorNotifier, autoscroller, border, changeSupport, clientProperties, flags, 
HAS_FOCUS, IS_DOUBLE_BUFFERED, IS_OPAQUE, IS_PAINTING_TILE, KEYBOARD_BINDINGS_KEY, 
listenerList, maximumSize, minimumSize, NEXT_FOCUS, paintlminediatelyClip, 
paintingChild, preferredSize, readObjectCallbacks, REQUEST_FOCUS_DISABLED, tmpRect, 
TOOL_TIP_TEXT_KEY, ui, uiClassID, UNDEFINED_CONDITION, vetoableChangeSupport, 
WHEN_ANCESTOR_OF_FOCUSED_COMPONENT, WHEN_FOCUSED, WHEN IN FOCUSED WINDOW 


Fields inherited from class java.awt.Container 

component, containerListener, containerSerializedDataVersion, dispatcher, layoutMgr, 
maxSize, ncomponents, serialVersionUID 


Fields inherited from class java.awtComponent 

actionListenerK, adjustmentListenerK, appContext, assert, background, 
BOTTOM_ALIGNMENT, CENTER_ALIGNMENT, changeSupport, componentListener, 
componentListenerK, componentOrientation, componentSerializedDataVersion, 
containerListenerK, cursor, dropTarget, enabled, eventMask, focusListener, 
focusListenerK, font, foreground, hasFocus, height, incRate, inputMethodListener, 
inputMethodListenerK, isinc, isPacked, itemListenerK, keyListener, keyListenerK, 
LEFT_ALIGNMENT, locale, LOCK, minSize, mouseListener, mouseListenerK, 
mouseMotionListener, mouseMotionListenerK, name, nameExplicitlySet, newEventsOnly, 
ownedWindowK, parent, peer, peerFont, popups, prefSize, RIGHT_ALIGNMENT, 
serialVersionUID, textListenerK, TOP_ALIGNMENT, valid, visible, width, 
windowListenerK, x, y 


Constructor Summary 

Pro to typeMenu (caps . CAPSMain. CAPSMainWindow owner) 

Constructor for this class. 


Method Summary 

void 

actionPerformed(j ava.awt.event,ActionEvent e) 

Action event handler for the menu events. 

void 

processCommitWorkMenuItem () 

Handles the event which is caused by selecting the 'Commit' menu item. 

void 

processNewMenuItem {) 

Handles the event which is caused by selecting the 'New' menu item. 

void 

processOpenMenuItem() 

Handles the event which is caused by selecting the 'Open' menu item. 
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Methods inherited f rom class javax-swing.JMenu _ 

, add, add, add, add, addMenuListener, addSeparator, buildMenuElementArray, 
clearListenerRegistry, createActionChangeListener, createMenuChangeListener, 
createWinListener, doClick, ensurePopupMenuCreated, fireMenuCanceled, 
fireMenuDeselected, fireMenuSelected, getAccessibleContext, getComponent, getDelay, 
getitem, getItemCount, getMenuComponent, getMenuComponentCount, getMenuComponents, 
getPopupMenu, getPopupMenuOrigin, getSubElements, getUIClassID, insert, insert, 
insert, insertSeparator, isMenuComponent, isPopupMenuVisible, isSelected, isTearOff, 
isTopLevelMenu, nienuSelectionChanged, parainString, processKeyEvent, 
registerMenuItemForAction, remove, remove, remove, removeAll, removeMenuListener, 
setAccelerator, setDelay, setMenuLocation, setModel, setPopupMenuVisible, 
setSelected, translateToPopupMenu, translateToPopupMenu, 

unregisterMenuItemForAction, updateUI, writeObject ___ 


Methods inher ited from class javax.swing.JMenuItem ___ 

addMenuDragMouseListener, addMenuKeyListener, alwaysOnTop, fireMenuDragMouseDragged, 
fireMenuDragMouseEntered, fireMenuDragMouseExited, fireMenuDragMouseReleased, ^ 
fireMenuKeyPressed, fireMenuKeyReleased, fireMenuKeyTyped, getAccelerator, init, 
isArmed, processKeyEvent, processMenuDragMouseEvent, processMenuKeyEvent, 
processMouseEvent, readObject, removeMenuDragMouseListener, removeMenuKeyListener, 
setArmed, setEnabled, setUI _ _____ 


Methods inhe rited from class javax.swing.AbstractButton ___ 

addActionListener, addChangeListener, addItemListener, checkHorizontalKey, 
checkVerticalKey, createActionListener, createChangeListener, createltemListener, 
doClick fireActionPerformed, fireltemStateChanged, fireStateChanged, 
getActionCommand, getDisabledIcon, getDisabledSelectedIcon, getHorizontalAlignment, 
getHorizontalTextPosition, geticon, getLabel, getMargin, getMnemonic, getModel, 
cietPressedIcon, getRolloverIcon, getRolloverSelectedIcon, getSelectedIcon, 
getSelectedObjects, getText, getUI, getVerticalAlignment, getVerticalTextPosition, 
isBorderPainted, isContentAreaFilled, isFocusPainted, isRolloverEnabled, 
paintBorder, removeActionListener, removeChangeListener, removeltemListener, 
setActionCommand, setBorderPainted, setContentAreaFilled, setDisabledlcon, 
setDisabledSelectedIcon, setFocusPainted, setHorizontalAlignment, 

setHorizontalTextPosition, seticon, setLabel, setMargin, setMnemonic, setMnemonic, 
setPressedIcon, setRolloverEnabled, setRolloverIcon, setRolloverSelectedIcon, 
setSelectedIcon, setText, setUI, setVerticalAlignment, setVerticalTextPosition_ 
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Methods inherited from class javax.swing.JComponent 

_paintImmediately, addAncestorListener, addNotify, addPropertyChangeListener, 
addPropertyChangeListener, addVetoableChangeListener, adjustPaintFlags, 
bindingForKeyStroke, checklfChildObscuredBySibling, computeVisibleRect, 
computeVisibleRect, contains, createToolTip, enableSerialization, 
firePropertyChange, firePropertyChange, firePropertyChange, firePropertyChange, 
firePropertyChange, firePropertyChange, firePropertyChange, firePropertyChange, 
firePropertyChange, fireVetoableChange, getActionForKeyStroke, getAlignmentX, 
getAlignmentY, getAutoscrolls, getBorder, getBounds, getClientProperties, 
getClientProperty, getComponentGraphics, getConditionForKeyStroke, 
getDebugGraphicsOptions, getFlag, getGraphics, getHeight, getinsets, getinsets, 
getLocation, getMaximumSize, getMinimumSize, getNextFocusableComponent, 
getPreferredSize, getRegisteredKeyStrokes, getRootPane, getSize, getToolTipLocation, 
getToolTipText, getToolTipText, getTopLevelAncestor, getVisibleRect, getWidth, getX, 
getY, grabFocus, hasFocus, isDoubleBuffered, isFocusCycleRoot, isFocusTraversable, 
isLightweightComponent, isManagingFocus, isOpaque, isOptimizedDrawingEnabled, 
isPaintingTile, isRequestFocusEnabled, isValidateRoot, keyboardBindings, paint, 
paintChildren, paintComponent, paintImmediately, paintImmediately, paintWithBuffer, 
processComponentKeyEvent, processFocusEvent, processKeyBinding, processKeyBindings, 
processKeyBindingsForAllComponents, processMouseMotionEvent, putClientProperty, 
rectanglelsObscured, rectanglelsObscuredBySibling, registerKeyboardAction, 
registerKeyboardAction, registerWithKeyboardManager, removeAncestorListener, 
removeNotify, removePropertyChangeListener, removePropertyChangeListener, 
removeVetoableChangeListener, repaint, repaint, requestDefaultFocus, requestFocus, 
resetKeyboardActions, reshape, revalidate, scrollRectToVisible, setAlignmentX, 
setAlignmentY, setAutoscrolls, setBackground, setBorder, setDebugGraphicsOptions, 
setDoubleBuffered, setFlag, setFont, setForeground, setMaximumSize, setMinimumSize, 
setNextFocusableComponent, setOpaque, setPaintingChild, setPreferredSize, 
setRequestFocusEnabled, setToolTipText, setUI, setVisible, shouldDebugGraphics, 
superProcessMouseMotionEvent, unregisterKeyboardAction, 
unregisterWithKeyboardManager, update 


Methods inherited from class java.awt.Container 

add, add, add, add, addContainerListener, addlmpl, applyOrientation, 
countComponents, deliverEvent, dispatchEventlmpl, dispatchEventToSelf, doLayout, 
eventEnabled, findComponentAt, findComponentAt, getComponent, getComponentAt, 
getComponentAt, getComponentCount, getComponents__NoClientCode, getComponents, 
getCursorTarget, getLayout, getMouseEventTarget, getWindow, initIDs, insets, 
invalidate, invalidateXree,.isAncestorOf, layout, lightweightPrint, list, list, 
locate, minimumSize, nextFocus, paintComponents, postProcessKeyEvent, 
postsOldMouseEvents, preferredSize, preProcessKeyEvent, print, printComponents, 
printOneComponent, processContainerEvent, processEvent, proxyEnableEvents, 
proxyRequestFocus, removeContainerListener, setCursor, setFocusOwner, setLayout, 
transferFocus, updateCursor, validate, validateTree 
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Methods inherited from class java.awt.Component _ 

action, add, addComponentListener, addFocusListener, addInputMethodListener, 
addKeyListener, addMouseListener, addMouseMotionListener, areInputMethodsEnabled, 
bounds, checkimage, checkimage, coalesceEvents, constructComponentName, contains, 
createlmage, createlmage, disable, disableEvents, dispatchEvent, enable, enable, 
enableEvents, enableInputMethods, getBackground, getBounds, getColorModel, 
getComponentOrientation, getCursor, getDropTarget, getFont_NoClientCode, getFont, 
getFontMetrics, getForeground, getInputContext, getInputMethodRequests, 
getIntrinsicCursor, getLocale, getLocation, getLocationOnScreen, getName, 
getNativeContainer, getParent_NoClientCode, getParent, getPeer, getSize, getToolkit, 
getToolkitlmpl, getTreeLock, getWindowForObject, gotFocus, handleEvent, hide, 
imageUpdate, inside, isDisplayable, isEnabled, isEnabledlmpl, isLightweight, 
isShowing, isValid, isVisible, keyDown, keyUp, list, list, list, location, 
lostFocus, mouseDown, mouseDrag, mouseEnter, mouseExit, mouseMove, mouseUp, move, 
nextFocus, paintAll, postEvent, preparelmage, preparelmage, printAll, 
processComponentEvent, processInputMethodEvent, processMouseEvent, remove, 
removeComponentListener, removeFocusListener, removeInputMethodListener, 
removeKeyListener, removeMouseListener, removeMouseMotionListener, repaint, repaint, 
repaint, resize, resize, setBounds, setBounds, setComponentOrientation, 
setDropTarget, setLocale, setLocation, setLocation, setName, setSize, setSize, show, 
show, size, toString, transferFocus _ 


Methods inher ited from class java.lang.Object ___ 

clone, equals, finalize, getClass, hashCode, notify, notifyAll, registerNatives, 
wait, wait, wait _ 


Field Detail 


newMenuItem 

private javax.swing.JMenuItem newMenuItem 

Initiates the 'New' event 


openMenuItem 

private javax.swing.JMenuItem openMenuItem 

Initiates the 'Open' event 


commitWorkMenuItem 

private javax.swing.JMenuItem commitWorkMenuItem 

Initiates the 'Commit Work' event 
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retrieveMenuItem 


private javax.swing.JMenuItem retrieveMenuItem 

Initiates the 'Retrieve From DDE' event 


quitMenuItem 

private javax.swing.JMenuItem quitMenuItem 

Initiates the 'Quit' event 


ownerWindow 

protected caps.CAPSMain.CAPSMainWindow ownerWindow 
The main window which owns this menu. 


Constructor Detail 


PrototypeMenu 

public PrototypeMenu(caps.CAPSMain.CAPSMainWindow owner) 

Constructor for this class. 

Parameters: 

owner - The main window which has created this menu. 


Method Detail 


actionPerformed 

public void actionPerformed(java.awt.event.ActionEvent e) 

Action event handler for the menu events. 

Specified by: 

actionPerformed in interface java.awt.event.ActionListener 
Parameters: 

e - The action event that is created by selecting a menu item from this menu 


processNewMenuItem 

public void processNewMenuItem() 
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Handles the event which is caused by selecting the 'New' menu item. 


processOpenMenuItem 

public void processOpenMenuItem() 

Handles the event which is caused by selecting the 'Open' menu item. 


processCommitWorkMenuItem 

public void processCommitWorkMenuItem () 

Handles the event which is caused by selecting the 'Commit' menu item. 


Tree Deprecated Index Help 

PREV CLASS NEXT CLASS FRAMES NO FRAMES 

SUMMARY: INNER | FIELD \ CONSTR | METHOD 


Class 


DETAIL: FIELD | CONSTR ] METHOD 



APPENDIX E: ACRONYMS 


CAPS 

Computer Aided Prototyping System 

CASE 

Computer Aided Software Engineering 

CDR 

Common Data Representation 

CGI 

Common Gateway Interface 

CORBA 

Common Object Request Broker Architecture 

CPL 

Common Prototyping Language 

DCOM 

Distributed Component Object Model 

Dll 

Dynamic Invocation Interface 

Dll COE 

Defense Information Infrastructure Common Operating Environment 

DOD 

Department of Defense 

DSI 

Dynamic Skeleton Interface 

GAMBITS 

Graphical Approach to Modeling and Building Interactively a 


Technical System 

GUI 

graphical user interface 

HIS 

Heterogeneous Systems Integrator 

HTTP 

Hypertext Transfer Protocol 

IDE 

integrated development environments 

IDL 

Interface Definition Language 

JDK 

Java Developer Kit 

JDS 

Jackson Development System 

JVM 

Java Virtual Machine 

LAN 

local area network 

OMA 

Object Management Architecture 

OMG 

Object Management Group 

ORB 

Object Request Broker 

PC 

personal computer 

PROTOTECH 

Prototyping Technology 

PSDL 

Prototype System Design Language 

RaPIER 

Rapid Prototyping to Investigate End-user Requirements 

RMI 

Remote Method Invocations 

RPC 

remote procedure call 

SSDL 

System Specification and Design Language 

UML 

Unified Modeling Language 

WAN 

wide area network 

WWW 

World Wide Web 
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